Normalize emails_[en/dis]abled param response in API
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=458823) </details> <!--IssueSummary end--> The following discussion from !151065 should be addressed: - [ ] @hfyngvason started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/151065#note_1885926507): (+2 comments) > What should happen if both are provided? The way it is right now, the deprecated field always wins, which seems like the opposite of what we want. Options: > > 1. keep things as-is > 2. non-deprecated field wins > 3. or, be a 400 if both are present and they have inconsistent values > 4. or, always be a 400 when both are present > > I like (3) because it catches probable bugs while also enabling the same code to support multiple GitLab versions (especially important during a zero-downtime upgrade). Conversely, I don't like (4) because that would complicate such upgrades. > > What do you think?
issue