Move Summarization to background

[heliocliu]

Related to #4910

As part of the loader/container/summarizer refactoring, we should investigate moving summarization into the background by way of a webworker or similar. Once created, the summarizing client ideally should not communicate with the main client or vice versa, which simplifies the handling of the background task.

[ghost]

This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!

[arinwt]

I think this is doable. Given how it currently works, the minimum information we would need would be an exchange of clientIds.

Summarizer client would like to know if its parent disconnected, so it can close itself. It could do this monitoring the Quorum, but needs to know its parent clientId.

Parent client would like to know if its spawned summarizer client disconnected/closed, so it can spawn a new one. It could also do this monitoring the Quorum, but needs to know the summarizer's JOIN seq clientId. I imagine that however we request the summarizer client, should be able to asynchronously inform the parent: (a) when it connects, giving the clientId, or (b) when it fails to connect, so that the parent doesn't need to rely on a timeout- i.e. solves "how long do we wait for our summarizer client to show up in the Quorum".

There are other ways we could implement this, but we do need some level of information exchanged between the two clients/containers so that they can ensure they are doing their best to keep a summarizer active.

[ghost]

This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!

[heliocliu]

captured better in #7996