Prevent admin Workspaces OAuth app misconfigurations
<!--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=551286) </details> <!--IssueSummary end--> MR: Pending <!-- NOTE: For context on MR heading, see: https://handbook.gitlab.com/handbook/engineering/devops/dev/create/remote-development/index.html#relationship-of-issues-to-mrs --> ## Description In https://gitlab.com/gitlab-org/gitlab/-/issues/545064+ , we introduced a new GitLab instance wide OAuth application for Workspaces. This OAuth application can technically be modified by the instance administrators. We want to present a warning when they do modify it; on similar lines as https://gitlab.com/gitlab-org/gitlab/-/merge_requests/157093+ . This will ensure admins are aware of the risks of modifying the configuration for the OAuth application. <!-- OPTIONAL: Is this a feature/enhancement? - Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole. - Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality. --> <!-- OPTIONAL: Is this a bug? Please uncomment and include the following: - **Current behavior:** - **Expected behavior:** - **Steps to reproduce:** - **Additional information:** please include VSCode version, browser dev tool logs, etc that might be helpful to debug the issue! --> ## Acceptance criteria - [ ] A warning banner is displayed if anyone tries to modify the Workspaces OAuth application - [ ] All new code and logic should be namespaced under the `remote_development` bounded context / namespace. ## Implementation plan The implementation of this should be virtually identical to the OAuth app behavior for the Web IDE. It shouldn't be necessary to DRY up the logic between the two implementations, it's only two instances of it. <!-- NOTE: Feel free to expand with more sections and headers as needed --> <!-- DO NOT TOUCH BELOW -->
issue