Add support for multi-user features

[benbrown]

This is an umbrella issue for multi-user features that will link to more specific tasks.

Is your feature request related to a problem? Please describe.

It is currently not possible for multiple users to simultaneously use a single shared instance of Composer. This prevents users from hosting Composer on a website, and makes it difficult to collaborate.

Scenarios

Composer should be updated to allow multiple simultaneous sessions that will allow the following scenarios (all assume a single shared instance of Composer running on a shared web resource):

• a developer wants to open 2 dialogs from same bot in different tabs
• a developer wants to open 2 different bots in different tabs
• a developer wants to open a dialog in one tab, and an LG file in another tab.
• Developer wants to open a dialog in one tab while a second developer edits the LG from that dialog
• 2 developers want to open the same bot
• 2 developers want to open different bots
• A developer wants to send a link to a specific dialog to another developer using the same instance of Composer
• A developer is prevented from overwriting changes to a document made in another tab or by another user

Required Changes

The work required to implement this functionality can largely be described as allowing multiple instances of the browser "client" to be served by a single instance of the Node-based "server." These clients may be a single user with multiple tabs open, or multiple users on different machines.

Broadly, this will require that the client specify the identity of the bot being modified as part of (most) API requests, and for the server to be updated to use this information to make modifications to the appropriate resources.

Basic Multi-user support

• Update the server to generate and store a unique bot ID for every bot project that is opened #1917: Update the server to generate and store a unique bot ID for every bot project that is opened. This bot ID must point to the actual "path" to the bot in storage.
• Update client code to receive and pass back a bot ID #1918: Update client code to receive and pass back the bot ID
• Update client code to receive and pass back a bot ID #1918: Update client code to include bot ID in the URLs such that /dialogs/main is now /bot/:ID:/dialogs/Main and ensure that, given a bot id in the url, the application is instantiated with the proper configuration and parameters (in other words, enable deep links)
• Track down other code in the server that might be storing remote user state unnecessarily

Prevent content overwrite

The application should prevent a user from overwriting changes by another user (or by same user in a different tab). If changes have occurred since the user initially loaded the document, changes should be discarded and an error message should be presented informing the user they should reload the page.

This will prevent key issues we've already heard from customers including overwriting yourself by editing in the wrong tab, and coworker overwriting newer changes with an old instance of an editor.

For reference, see a previous ticket on this subject #1330

• When the server provides content from a bot project, it should include the last modified time of each piece of content
• When a write operation is made from the client, the last modified time should be passed back down to the server.
• Before any write operation is undertaken, check the provided last modified time against the current last modified time from the document in storage. If provided < current, reject the write. If provided >= current, accept it and return a new last modified time to the client.
• The client should update its internal last modified time for a given document any time a successful write operation occurs.
  • this is slightly tricky, as in our current implementation, we are debouncing the save action. however, since according to docs, "subsequent calls to the debounced function return the result of the last func invocation." it is feasible that each save action can pass its updated timestamp down to the next.
• The client should present a notification and disable the editing UI when a write is rejected. Present a button to reload the page or at least reload the current document to enable editing.

[ON HOLD] Support in language servers

These changes will now not be necessary because the language servers are moving into the client.

• Ensure language servers have access to composer config data where mapping is stored
• Update the language servers to support multiple simultaneous bot projects
• Update client calls to language servers to include the bot project ID
• Store indexed information for each bot project in a memory cache along with a last accessed timestamp
• Purge information from memory cache that has not been accessed for > 5 minutes

[benbrown]

For the record, what is not included in the scope of this work is auth and identity. Authentication (am I allowed to do access this) and identity (who is accessing this) will be implemented at the plugin layer, allowing these to be connected to arbitrary outside systems such as AAD, oauth, etc.

Personalization is also excluded from the scope. For example, the recently opened bots list can continue to be "global", as well as any Composer-level configuration options.

[benbrown]

I am working on this now!

[benbrown]

These changes are (or will be soon) present in #2023