Refactored validations rules for has_secure_password

[chancancode]

It primarily fixes #13753, but also addresses a few other issues I encountered along the way:

1. When validation is enabled, and a model is saved without a password with user.save(validate: false), a runtime error is raised
2. It is not possible to clear the password with user.password = nil, even though the docs on that method seems to suggest otherwise. (When you don't have validations on, it makes sense that you should be allowed to clear the password, and I think it's better to stick with password= for that rather than encourage users to mess with with password_digest= directly)
3. When validation is enabled, it is possible to save a record without a password(_digest) (bug number 2 makes this not very plausible now, but if that's fixe, you'll be able to do user.update!(password: nil))

Reason for these bugs

I traced the git history, and I think in multiple attempts to fix the validation messages, the intention of the original validations were lost in translation.

If I am reading the history right, I think the original intention of the validation rules is to make sure your user model will always have a password.

In that regard, the original rules are actually spot on. It covers the case when you create a new model (when you set password=, it'll generate a password_digest at the same time, so it passes) and updating an existing model (when you fetch an existing record from the DB, it'll have password_digest set, even though the virtual attribute password is nil).

The only problem with that rule is that the error message will becomes "password digest can't be blank" which is obviously not what you want to show the users. When trying to fix this problem (#6185, #6215; cc @erichmenge @josevalim) we misinterpreted the intention of the rule and ended up adding an unnecessary before_create callback and missed the update case (bug 3). (It's unnecessary because if password= is working correctly password_digest will always be non-empty on create.)

So I rewrote the tests to spell out all the possible cases and refactored the rules. The end-result also passes all but two (invalid) test cases in the old test suite.

The only thing that changed (besides the bugs were fixed) is that having a non-empty password but an empty password_confirmation now gives "Password confirmation does not match Password" instead of "Password confirmation can't be blank". This seems fine to me. That rule was added in #10694 (cc @steveklabnik), and it seems like the primary driver of that PR is just to cover the "create a new user with validation and a blank password confirmation" scenario which is covered here. If the original message is desirable, I can easily add it back.

I'm not too sure about the extra-verbose tests, but that's what I used to give me safety during my refactor, so I left them there.

Marked as [WIP] because I need to go through all the commits again to make sure I didn't unfix any old bugs by accident.

cc @carlosantoniodasilva

[chancancode]

I forgot to mention, authenticate will not work when password_digest is nil. But that's probably expected if you try to authenticate against a user that didn't have a password, so I think that's fine. In any case, that behaviour is not new in this PR.

[lukesarnacki]

This looks awesome 👍 :)

[why-el]

looks good to me.

[robin850]

I guess this is "will make" here, no ?

Awesome work so far Godfrey! 👏 ❤️

[chancancode]

You're correct sir!

[rafaelfranca]

[egilburg]

don't need self here I think

[chancancode]

Still haven't had a chance to review the existing commits yet, but other than that and the few minor things noted above, I think this is good to go. So, I'll do a full review asap, and when I'm done I'll probably merge this. If you have any (potential) objections, let me know soon :)