fix: password reset leaks user existence

[SychO9]

Part of the security roadmap

Changes proposed in this pull request:

• Removes unknown user error, throws a validation error instead.
• Moves password reset logic to a job to prevent leak by duration.

Reviewers should focus on:
I wonder if we should drop the command and move it to the controller now that we also added a job. Would that be a possible breaking change?

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

[davwheat]

We might want to consider sending emails to users when their emails aren't registered (ratelimited, obviously) so that a user doesn't sit aimlessly for minutes if they enter one of two emails they might have used, for example.

I know some other services do this, with something like "You've requested a password reset, but we didn't find a user associated with this email address", etc.

[SychO9]

hmm 🤔 I don't know if we would want to send emails to non-registered users, but yeah would definitely require rate limiting which would need to be implemented separately as it would be a cache-based implementation possibly reusing the laravel one and allowing for easy re-usage.

[davwheat]

Yeah, fair point. We should be extra careful about spam to non-users.