Remove presence validator on name on WebauthnRegistration

What does this MR do and why?

This fix is being made as per the discussion and findings from &4061 (comment 726298377) (and the rest of the thread)

The major details (summarized) are:

• We are in the process of moving from U2f to Web Authentication for 2FA. (#22506 (closed))

• As part of this, we have introduced an after_commit callback on U2fRegistration model named create_webauthn_registration, that creates a new WebauthnRegistration record for the corresponding U2fRegistration record. We also ran a migration to create corresponding records of existing U2fRegistration records.

• This change was deployed a while ago.

• While most of the corresponding records were created successfully via the callback and the migration, we noticed that 70 U2fRegistration records on gitlab.com database are missing the corresponding WebauthnRegistration records.

• On further investigation, we noticed that 64 out of the 70 of these records failed to create the new records because:

  • The U2fRegistration records had its name as blank (' '). This is allowed as per the db, because the attribute is name character varying on this table. So it allows both NULL and blank values for name.
  • But on WebauthnRegistration, we had a presence validator on name, that does not allow blank values.
  • At the db level, we have WebauthnRegistration's name attribute as name text NOT NULL
  • NOT NULL constraint allows blank strings as names.
  • So, for the migration to take place successfully, the blank names in U2fRegistration should become blank names on WebauthnRegistration records. And for that to work, we should remove the presence validator on name from WebauthnRegistration, which is what this MR does.
  • And it also replaces the presence validator on name with a not null validator.
  • This will make sure that these 64 records will have its corresponding WebauthnRegistration record created if we run the background migration again.

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.