Fix bug in U2fRegistration after_update callback

What does this MR do and why?

• In a pipeline for a separate MR, rspec undercover flagged that this was not tested: https://gitlab.com/gitlab-org/gitlab/-/jobs/2778676259

• Specs for the existing behavior revealed that this callback was not called as expected due to the activerecord dirty condition

• In ActiveRecord 5.1, the following deprecation message was added:

    DEPRECATION WARNING: The behavior of `attribute_changed?` inside of
    after callbacks will be changing in the next version of Rails. The new
    return value will reflect the behavior of calling the method after
    `save` returned (e.g. the opposite of what it returns now). To maintain
    the current behavior, use `saved_change_to_attribute?` instead.

• Starting with Rails 5.2 (we are currently on Rails 6.1.6.1), within an after_update callback, attribute_changed? now returns false even if the attribute was changed.

• So in this case, changes to the counter attribute were not triggering this callback (because it was checking for counter_changed? which would always return false in an after_update context).

• Updating the callback to saved_change_to_<attribute> fixes the issue: https://github.com/rails/rails/blob/04972d9b9ef60796dc8f0917817b5392d61fcf09/activerecord/lib/active_record/attribute_methods/dirty.rb#L86-L92

• Resources:

  • https://github.com/rails/rails/issues/29035#issuecomment-423085336
  • https://www.fastruby.io/blog/rails/upgrades/active-record-5-1-api-changes.html

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.