Validator extender

[askvortsov1]

Fixes part of #1891

Changes proposed in this pull request:

• Add Validator extender with configure method
• Add integration tests
• Deprecate Validating event

Reviewers should focus on:
I slightly deviated from the previously discussed spec on this one, as I think that having a configure method that runs the validator through a callable gives us and developers more flexibility than simply the ability to add rules. Similarly, there are extensions that depend on this type of capabilities.

Should there be a dedicated method to run the ruleset through a callable as well? I'm not sure if that is necessary (this PR supports that), but it might be a nice shortcut.

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).

[franzliedke]

Similarly, there are extensions that depend on this type of capabilities.

Could you provide a few examples / links? It's hard to think about this in the abstract.

[askvortsov1]

Could you provide a few examples / links? It's hard to think about this in the abstract.
https://github.com/FriendsOfFlarum/doorman/blob/bb428bcc6aa2e2f30d91fbe7361d7e7e3c19249c/src/Listeners/AddValidatorRule.php
https://github.com/FriendsOfFlarum/recaptcha/blob/b9df60ff5604c61e621b479c88823855212564f0/src/Listeners/AddValidatorRule.php
https://github.com/clarkwinkelmann/flarum-ext-passwordless/blob/a772005219b4005c8a4105c50e3f137093c90918/src/Listeners/DontRequirePasswordOnSignUp.php

Really, the only/biggest question is what to do with validator extensions, as they will often require DI)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[askvortsov1]

Not stale

[clarkwinkelmann]

The deprecation messages will need to be updated (beta13 => beta14)

Regarding the code of the test, I'm not sure whether we want to explain what it does or simplify it? I believe it's copied from one of my example and the reason it's so complex is to keep the additional password rules that might have been made by other extensions. I think having a comment reminding that would be useful for future readers.

Or we could also use a shorter code that blindly replaces the rules without regard for other extensions. This might be something legitimately used in the local extend.php when the list of extensions is well known. Something like: (untested)

        $this->extend((new Extend\Validator(UserValidator::class))->configure(function ($validator) {
                $validator->setRules([
                    'password' => [
                        'required',
                        'min:8'
                    ]
                ] + $validator->getRules());
            }
        }));

I think it would still make sense to pass the Flarum validator object to the callback. It could be the second param instead of the first like it was with the event. Sometimes values are stored on that object, for example the user instance on UserValidator.

There's also the not-exactly-related-but-somewhat-close matter of #2398 where an event might or might not make sense (?)

[clarkwinkelmann]

I have not tested locally, but this looks good 👍

Should the tests cover calling a callback/class that takes a single argument? This is something that should work in PHP? One of the two (callback or class) could omit the second argument on purpose (with a comment explaining it's omitted)