Implement mechanism for injecting settings and feature flags to WebIDE workflow
<!--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>
- [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=412448)
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=412448)
</details>
<!--IssueSummary end-->
## Problem Statement
The WebIDE and Desktop environments have different way of setting feature flags and settings. We need to create abstraction for settings/FF that will be used by shared features in WebIDE and Desktop.
### Vocabulary
- WebIDE - browser VS Code started on the `/-/ide/` route
- Desktop - VS Code installed on your computer
### Suggestions
Create graphql end points for IDE related settings, and feature flags
```graphql
{
currentUser {
id
username
ide {
codeSuggestionsEnabled
userCodeSuggestionsEnabled
groupCodeSuggestionsEnabled
thirdPartyAIFeaturesEnabled
featureFlags {
ideCodeSuggestions
ideFloatingToolbar
}
}
}
}
```
### The difference
Desktop Workflow uses two types of configuration:
- `settings.json` - there are many properties in the `settings.json` that configure the behaviour of the Desktop Workflow some examples are:
- `gitlab.showStatusBarLinks` - should we show the status bar icons?
- `gitlab.showPipelineUpdateNotifications` - when pipeline finishes, should we show notification?
- `gitlab.featureFlags` property in `settings.json` - when we release unfinished features, we hide them behind a feature flag. The `featureFlags` property contains an array of strings. We then check if the feature flag is enabled with:
- `if (getExtensionConfiguration().featureFlags?.includes(SECURITY_SCANS_FEATURE_FLAG))`
- [(code)](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/3fc7957362f3ebd0db1dee3c2f6eb9919a446e97/src/tree_view/current_branch_data_provider.ts#L110)
The WebIDE now has two types of configuration:
- `settings.json` - you can still change `settings.json` (the "file" is stored in browser local storage)
- [`ClientOnlyConfig`](https://gitlab.com/gitlab-org/gitlab-web-ide/blob/346fd036b76d15f8dc90b3e55947a7f27218ce0c/packages/web-ide-types/src/config.ts#L48-80) - this is configuration that WebIDE receives from Rails
### Example: Code Suggestions
On Desktop, you can enable code suggestions with `gitlab.aiAssistedCodeSuggestions.enabled` property in `settings.json`.
In the WebIDE, we now set the default value for `gitlab.aiAssistedCodeSuggestions.enabled` in `settings.json` ([see Option 2 here](https://gitlab.com/gitlab-org/gitlab/-/issues/411411#note_1427262978)).
This however means that the user can override the value and enable code suggestions in WebIDE.
## Solution
We need to design a "mindset" for the WebIDE. Desktop is simple, you have the VS Code running on your machine, and you configure it with one file.
But WebIDE will have to have a combination of
- users changing `settings.json` (e.g. you want to change the default VS Code behaviour, you wouldn't want to configure this in your GitLab profile)
```json
{
"workbench.statusBar.visible": true,
"editor.minimap.enabled": false,
"extensions.ignoreRecommendations": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"explorer.confirmDragAndDrop": false,
"prettier.singleQuote": true
}
```
- users or instance admins changing features that are enabled for the extension (e.g. the code suggestions)
**We should consider an option that API requests should drive these decisions about what features to enable/disable so we can keep the same behaviour on Desktop and in WebIDE.**
<details><summary>Exit criteria</summary>
## Requirements
- Design a robust and scalable solution for injecting configuration settings and feature flags into the WebIDE.
- Implement the unified approach for both browser and desktop versions of the WebIDE.
- Ensure that the solution supports dynamic updates to configuration settings and feature flags without requiring a restart of the WebIDE.
- Validate the functionality and effectiveness of the unified approach through comprehensive testing, including various scenarios and edge cases.
- Document the usage and implementation details of the new approach in the WebIDE documentation.
- Conduct a review and feedback session with the development team to gather insights and address any concerns or suggestions regarding the new approach.
- Obtain approval from the relevant stakeholders, including the product owner or project manager, for the implemented solution.
- Communicate the availability and benefits of the new approach to the wider development community.
</details>
## Open items
This endpoint will give the raw choice for all IDEs, Feature flag will go into the `ideSettings { featureFlags` area. But I've added this in the issue as a discussion item.
issue