feat(webinar): refactor Mercury / LLM to support multiple connections

[mickelr]

COMPLETES #< INSERT LINK TO ISSUE >

https://jira-eng-gpk2.cisco.com/jira/browse/SPARK-697743

This pull request addresses

Refactor Mercury and LLM plugin to support mulitple data channel connections at the same time

by making the following changes

Use a map to maintain multiple sockets in Mercury
Each socket can be identified by a session id
A default session id will be generated for backward compatibility

Change Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Tooling change
• Internal code refactor

The following scenarios were tested

< ENUMERATE TESTS PERFORMED, WHETHER MANUAL OR AUTOMATED >

The GAI Coding Policy And Copyright Annotation Best Practices

• GAI was not used (or, no additional notation is required)
• Code was generated entirely by GAI
• GAI was used to create a draft that was subsequently customized or modified
• Coder created a draft manually that was non-substantively modified by GAI (e.g., refactoring was performed by GAI on manually written code)
• Tool used for AI assistance (GitHub Copilot / Other - specify)
  • Github Copilot
  • Other - Please Specify
• This PR is related to
  • Feature
  • Defect fix
  • Tech Debt
  • Automation

I certified that

• I have read and followed contributing guidelines
• I discussed changes with code owners prior to submitting this pull request
• I have not skipped any automated checks
• All existing and new tests passed
• I have updated the documentation accordingly

---

Make sure to have followed the contributing guidelines before submitting.

[aws-amplify-us-east-2]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-4466.d3m3l2kee0btzx.amplifyapp.com

[Coread]

I am a little concerned when I see the oneFlight removed. This is usually to protect the service from us trying to make multiple simultaneous calls. Do you know what effect removing it will have?

[mickelr]

Yes, I have the same concern and hesitate to remove it. Considering the case that a panelist join a webinar which practice session is in progress, client need connect main session and practice session at the same time and the @ONEflight flag will block one of the two connections. Anyway, we can keep the decorator and add additional logic to make sure both connections can be established. What's your suggestion?

[Coread]

I personally hate the decorators, they are really confusing to try and work out what is going on. They are there to protect against multiple calls to e.g. connect which would otherwise trigger multiple websocket connection attempts. Maybe explicit progress states for each of the connections would be a better way of handling this.