Fix “Email changed” notification sometimes having wrong e-mail

[ClearlyClaire]

Fixes #6778

The root of the issue is that send_devise_notification was called before
the changes were properly commited to the database, causing the mailer to
pick previous values if running too early.

Devise's documentation provides guidance on how to handle 1 2, however,
I have found it to not be working, as the following happens, in that order:

• send_devise_notification is called for the email_changed notification.
  In that case, changed? is false and saved_changes? is true, so
  if we use the former, we have the same issue.
• the after_commit hook is called
• send_devise_notification is called for the confirmation_instructions
  notification.
  In that case, changed? is still false, and saved_changes? still true,
  so if we use the latter, that second notification email is simply not
  going to be sent.

This may arguably be a bug in Devise or Rails, but I haven't dug further
and instead opted for the following workaround: just postpone calling the
mailer by a few seconds.

EDIT: I ended up following Devise's documentation, except instead of relying on changed? or saved_changes?, which can't differentiate between a committed save and an uncommitted save, checking whether a transaction is open. This correctly queues the notification from after_update and immediately sends the one from after_commit.

[ClearlyClaire]

Looking at Devise's source code, the email_changed notification is sent in an after_update hook, so after save but before the transaction is committed, and the confirmation_instructions is sent in an after_commit hook. This explains why changed? would be false (the save did occur) and saved_changes? would be true (last save did save changes). I'm not sure how we could reliably tell whether the changes were committed though, so for now my best solution is still to delay running the mailer :/

[ClearlyClaire]

Found a better way and updated the PR accordingly!

[ClearlyClaire]

An update on the last changes I made: I figured send_devise_notification could be called when not creating/changing the user struct (e.g., re-sending the confirmation e-mail), and worse, it could be called when not changing it, but still being in a transaction (as is the case of one of the tests, apparently).

Therefore, I changed it to get queued when the record itself is in a pending transaction. I have tested this does save the issue at end, and it should not add any delay, and I guess the test could possibly be too strict (inclusion, instead of checking a record of that id exists), in which case it could possibly perform as badly as before, but not worse.