Invert emails_disabled into emails_enabled within GitLab REST API only

About

When Switch Groups UX to emails_enabled (!135959 - merged) added an ignore_column :emails_disabled to Namespace it unintentionally caused a breaking change to the REST Groups API. The create and update endpoints accept emails_disabled as a deprecated argument. As those endpoints did not adapt the deprecated param like the Project create and update API endpoints do, this meant that when people passed the emails_disabled argument through to the Groups endpoints the API would 500 as there was no such attribute recognised in the model any longer. This caused a severity3 incident gitlab-com/gl-infra/production#17775 (closed).

A fix was merged !148577 (merged) that defensively solved for all potential occurrences of when the old param was passed through to the group create and update services, and not just the API. It added a temporary shim to adapt any emails_disabled param to a emails_enabled param within those services.

Due to the temporary nature of the shim, we would like to remove it.

Proposal

The Group create and update API endpoints should adapt the emails_disabled argument to a emails_enabled param (like the Project create and update API endpoints do). This will let us remove the shim.

API v4 will then continue to adapt the param for as long v4 exists, as we cannot have breaking changes made to it even on major releases. But the handling of this will just be in the API layer.

We should also ensure we have API test coverage for this.

Edited by Luke Duncalfe