Changed ActiveModel::Validations::LengthValidator to take lambda as a value for dynamic validation

[jhsbeat]

Here is a suggesting change for the ActiveModel::Validations::LengthValidator to take lambda as a value for dynamic validation.
This commit is related to the requirements below:
http://stackoverflow.com/questions/32714439/dynamic-minimum-maximum-values-for-rails-mode-validates

In practice, there are some requirements to change min/max values in runtime however current length validator cannot support it because the option values are determined in class loading time.
To take dynamic change in validation, the options can take lambda to call the value dynamically.

I hope this change can be helpful. :)

[rails-bot]

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @arthurnn (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[sgrif]

I don't think this is a common enough use case to warrant this change (which would need documentation and tests if it were to be accepted). Overall, the goal has been to simplify the validators, and prune out edge cases. This use case can be easily accomplished by just using a method instead.

[jhsbeat]

@sgrif Thanks for your feedback.

[coorasse]

I'd ❤️ to see that implemented.
Maybe is not very common, true that, but the fact that it does not work out-of-the-box, is a surprising moment for the developer. I love the Rails principle of "it just works" and this pr goes in that direction.

[simi]

@coorasse it is really simple to roll out custom validation if you need more complexity than provided by validations provided by default.

https://guides.rubyonrails.org/active_record_validations.html#custom-methods

[pirtlj]

Sad to see this closed I think this use-case is more "common" than some might suspect. Also other properties consume blocks such as :in and :unless so my expectation as a user is that these properties could take Procs as well.