set valid_email to true on user email change

[Tooyosi]

Describe your change here.

Review checklist

• First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
• If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
• If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
• Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

[hound]

Rails/SkipsModelValidations: Avoid using update_attribute because it skips validations.

[hound]

Style/StringLiterals: Prefer single-quoted strings when you don't need string interpolation or special symbols.

[lcjohnso]

Closes #4278

[zwolf]

The spec needs to be modified a bit to test this behavior correctly. valid_email is not set in the user factory, so the database default of 'true' is used when a new user is instantiated. This is why the included test passes even though the user wasn't reloaded from the database: the valid_email attribute was true to begin with.

You need to create a new user with an invalid email in your spec:

let(:invalid_user) { create(:user, valid_email: false) }

Then, when you check that the attribute was changed in your spec:

expect(user.reload.valid_email).to be_truthy

The controller logic looks good, so this way you know that you started with an invalid email and can confirm that it was successfully changed.

[zwolf]

LGTM! For future reference, this is being done instead of using Devise's Reconfirmable module to avoid requiring users who have fixed or changed their email address to confirm. Since the initial confirmation is specifically to weed out spam, this is sufficient.