Split except into a separate validator and allow both to accept either check or list Procs

[jlfaber]

I'm not in love with the complexity of the values: validator (even though I contributed to some of it!) I think it would be cleaner to split out the except: functionality into its own separate top-level validator. In addition, I'd like for values: to take two different kinds of Proc -- the first, with an arity of zero, would simply return a dynamically calculated list of valid (or excluded) values. That's how it works today.

If, however, the arity of the supplied Proc is one, the param value in question would would be passed in and the Proc would be expected to return true or false. That's how the proc option of the values validator works today.

Some examples:

Current

params do
  requires :a, values: { value: 0..99, except: [3] }
  requires :b, values: { value: 0..99, except: [3], except_message: 'not allowed' }
  requires :c, values: { except: ['admin'] }
  requires :d, values: -> { my_obj.list_allowed_vals }
  requires :e, values: { proc: -> (v) { v.even? } }
end

Proposed

params do
  requires :a, values: 0..99, except_values: [3]
  requires :b, values: 0..99, except_values: { value: [3], message: 'not allowed' }
  requires :c, except_values: ['admin']
  requires :d, values: -> { my_obj.list_allowed_vals } # no change
  requires :e, values: -> (v) { v.even? }
end

I don't see any reason to allow arity one Procs with the except_values: validator since one could just use the values validator to do the same thing.

What I like about this proposal is that it restores values: to the old pattern of only needing a Hash if a custom message is to be used when it fails. And the new except_values: validator follows the same pattern.

I'm happy to do this work, but I wanted to solicit opinions before starting. If the concept is deemed sound, we'd also want to determine whether to replace or deprecate the existing functionality. Normally I'd say deprecate, but as we're looking at a major release, perhaps we don't need to?

[dblock]

This looks great to me. It could also make it into 1.0 easily if you need to make it a breaking change.

[jlfaber]

I think we might want to use a different name for the new validator. There's already an except: option on param lines so this might be confusing.

requires :all, except: [:ip], using: API::Entities::Status.documentation.except(:id)

Perhaps exclude:, forbid:, except_values:, or some other option would be better?

@dblock Thoughts?

[dblock]

I think except_values: would be consistent with except.

[jlfaber]

With #1616 merged, I think this can be closed.