Allow minimal access value for UserHighestRole [RUN AS-IF-FOSS]

What does this MR do and why?

This MR adds Gitlab::Access::MINIMAL_ACCESS to the array of allowed values for UserHighestRole.

We need to add this because currently attempts to update the highest role via the UpdateHighestMemberRoleService fail for users who this applies to, raising a validation error.

Currently this is resulting in two negative outcomes:

1. We are inaccurately storing the highest role a user has if they are downgraded to MINIMAL_ACCESS (because the update fails)
2. We have an large number of validation errors being raised in sidekiq due to these cases (internal: kibana)

In #342125 (closed) we discuss this problem and this proposed solution as part of a two step process. This MR addresses the problem for highest role updating and the resulting errors on GitLab.com.

The next step will be to add visibility into this access level via user statistics (self-managed).

Note: This is an EE change as the MINIMAL_ACCESS level is not available in FOSS.

How to set up and validate locally

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

1. Fire up an EE rails console (default)

   bin/rails c

2. Check level is valid:

   > UserHighestRole.new(user: User.last, highest_access_level: Gitlab::Access::MINIMAL_ACCESS).valid?
   => true 

3. Fire up a FOSS console:

   FOSS_ONLY=1 bin/rails c

4. Check level is invalid:

   > UserHighestRole.new(user: User.last, highest_access_level: Gitlab::Access::MINIMAL_ACCESS).valid?
   => false 

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.