Add support for server side profiles

[SanjulaGanepola]

Changes

This PR builds on #2942 to add support for server side profiles. The best approach from my testing to support multiple developers working on the same server profile, is to allow a checkout flow where users activate the server profile, freely make changes in their local copy and then explicitly push changes when ready.

Storage

When using Create new profile or Create new profile from current context, users will be prompted for the name of the profile as before, but will now also be prompted for the type of profile:

When users select Server, the profile will be stored in /etc/vscode/profiles.json. We will use the ConfigFile APIs to store the state of this file. All normal ConnectionProfile fields will be stored in server profiles except for the homeDirectory. I also introduced a new field called lastUpdated to track when the profile was last updated. This is to handle synchronization between multiple developers working on the same profile and is used to determine the server profile state (described further below). Example below:

[
    {
        "name": "My Server Profile",
        "currentLibrary": "QGPL",
        "libraryList": [
            "QGPL",
            "QTEMP"
        ],
        "customVariables": [],
        "ifsShortcuts": [
            "/home/SANJULA"
        ],
        "objectFilters": [],
        "lastUpdated": 1770679579920
    }
]

In the user's settings.json, I kept the currentProfile field in the connecting settings and introduced 2 new fields:

• currentProfileType: This is either local or server.
• currentProfileLastKnownUpdate: Similar to lastUpdated from profiles.json, but this is just the last known update at the time we loaded them. The actual lastUpdated could change when other developers make server profile changes, and so we compare these 2 to get the profile state (again, described further below).

Profile States and Actions

There are 3 different server profile states:

1. In Sync

This is when the local copy of the server profile is in sync (in terms of the ConnectionProfile fields).

2. Modified

This is when the local copy of the server profile is not in sync (in terms of the ConnectionProfile fields), but the timestamps are the same (currentProfileLastKnownUpdate and lastKnownUpdate). This means the user may have added/deleted/updated their library list, filters, custom variables, etc + no developer has pushed any other changes resulting in the timestamp to change.

The user can continue to freely work, but they can perform the following actions at any time to push their changes to server or discard them:

3. Out of Sync

This is when the local copy of the server profile is not in sync (in terms of the ConnectionProfile fields), but this time the lastKnownUpdate is ahead of the currentProfileLastKnownUpdate meaning that some other developers on the team pushed some changes.

Again, the user can continue to freely work, but they can perform the following actions at any time to force push their changes to server or discard them:

Profile State Management

As mentioned above, we will use the ConfigFile APIs to store the state of profiles.json. We want to avoid constantly having to reload this file from the server so instead we try our best to rely on the cached result when possible and only reload when necessary. The flow is described below:

• The profiles.json file is loaded and cached initially when connecting if it exists
• If the user presses the Refresh button on the Environment view, we will reload the file from the server as this is an explicit action
• When users have a server profile checked out and make changes locally (such as add new filters), they will see the profile state gets updated to Modified. Technically at any point if another developer happened to push some changes to the server profile, the profile would truly be in Out of Sync, but the user would continue to see Modified as we have not reloaded the file (unless they clicked the Refresh button). This is perfectly fine as we don't want to constantly reload the config file when users make changes to their local copy. Instead we will do a reload right before attempting to actually push any updates. This will be when users try to unload, try to rename, use Save Changes to Server, or Overwrite Changes to Server

Other Minor UI Improvements

• When editing a profile, Object filters will now show the name and description
• Unload active profile action moved from the Profiles heading node to the actual active profile

Next Steps

Following this, I am going to explore server side actions and adding the actions API (#2802)

How to test this PR

1. Test creation of local and server profiles (empty and from context)
2. Test rename of local and server profiles
3. Test deletion of local and server profiles
4. Test activating a local profile and profile is properly updated as changes are made
5. Test unloading of a local profile
6. Test activating a server profile
7. Test getting to a modified state and using both actions
8. Test getting to a out of sync state and using both actions (either manually open the file and make a change + increment the timestamp or sign in with another user and push and update)
9. Test unloading of a server profile
10. Test that the empty default profile ("") which is used when no profile is activated, does not lose changes when switching between different profiles

Checklist

• have tested my change

[github-actions]

👋 A new build is available for this PR based on 1859135.

• Download here.
• Read more about how to test