`UserHighestRole` does not consider `MINIMAL_ACCESS` to be a valid access level, leading to validation error

I noticed this problem while going thru Sentry errors. It shows UpdateHighestRoleWorker fails with Validation failed: Highest access level is not included in the list errors.

Digging into the problem, I figured this is because:

The model says:

class UserHighestRole < ApplicationRecord
  validates :highest_access_level, allow_nil: true, inclusion: { in: Gitlab::Access.all_values }
end

However, Gitlab::Access.all_values only includes GUEST, REPORTER, DEVELOPER, MAINTAINER, OWNER as access levels. This method has no override in EE.

Though, in EE, there is an additional access level of MINIMAL_ACCESS with value 5. Since this value of 5 is present in the access_level column in the members table, when there are UpdateHighestRoleWorker jobs that run Users::UpdateHighestMemberRoleService, which perform user_highest_role.update!(highest_access_level: 5) and it fails with validation error.

This leads to such jobs failing and being retried 3 times without ever being able to succeed. This can be prevented.

I see multiple ways to solve this problem (not exhaustive):

1. Also include MINIMAL_ACCESS as a valid access level in UserHighestRole
2. UserHighestRole is used to create statistics in UsersStatistics table, but it seems that we only care about the roles of GUEST, REPORTER, DEVELOPER, MAINTAINER, OWNER specifically, so we could very well do an early return if the highest role obtained from the members table does not match any of these roles. However, if we go with option (1), we could also start collecting statistics of MINIMAL_ACCESS in the UsersStatistics table in EE installations.