Draft: Allow 'nil' as API parameter value for `enabled_git_access_protocol`

What does this MR do and why?

Allow 'nil' as the parameter value when changing the enabled_git_access_protocol via the API, as documented:

Attribute	Type	Required	Description
enabled_git_access_protocol	string	no	Enabled protocols for Git access. Allowed values are: ssh, http, and nil to allow both protocols.

I believe the intention was for nil to mean sending a null value (or a key with no value):

curl -s -X PUT --header "PRIVATE-TOKEN: $TOKEN" --header 'content-type: application/json' \
  -d '{"enabled_git_access_protocol": null}' \
  'http://localhost:3000/api/v4/application/settings'
{"id":1,..."enabled_git_access_protocol":null,...}

However some clients don't accept parameters without a value. In any case, this change makes the behaviour strictly match the documentation.

Screenshots or screen recordings

Before:

❯ curl -s -X PUT --header "PRIVATE-TOKEN: $TOKEN" --header 'content-type: application/json' \
  'http://localhost:3000/api/v4/application/settings?enabled_git_access_protocol=nil'
{"message":{"enabled_git_access_protocol":["is not included in the list"]}}%

After:

❯ curl -s -X PUT --header "PRIVATE-TOKEN: $TOKEN" --header 'content-type: application/json' \
  'http://localhost:3000/api/v4/application/settings?enabled_git_access_protocol=nil'
{"id":1,..."enabled_git_access_protocol":null,...}

How to set up and validate locally

Execute the command as above, or the equivalent via your preferred API client (TOKEN must be an administrator).

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.

Related to #12944 (closed)