Connectivity eventing improvements

[vladsud]

Per https://office.visualstudio.com/OC/_workitems/edit/5489692?src=WorkItemMention&src-action=artifact_link, we need to

• expose "connect" event from Container, to allow hosts to know when connection has been established (and stop showing disconnected banner).
  • [update] -- @markfields will work with @scottn12 to clarify the ideal list of events, including updated names and very clear semantics/gaurantees. The plan is written up in Naming consistency for API/event surface related to Container's connection to delta stream #9677.
• Change when "connected" event is raised for "read" connections - make it fire only when container is up-to-date (based on what we know, i.e. checkpointSequenceNumber, maybe storage call coming back)
  • This will ensure that transition from "read" to "write" connection will not suddenly make container not up-to-date.

[vladsud]

@markfields - Curtis suggested assigning it to you
We can use waitContainerToCatchUp() for delaying raising "connected" event for "read" connections.

Here are two big considerations (outside of actual logic changes):

1. This will change timing of "connected" events as observed by hosts. They will report "regression". We need to work with them upfront to ensure they are aware of these changes and why things will change.
2. We will need to ensure that host / sharedUX has better handling for these events, including changes in UX itself. My expectation that they will use new "connect" event for today's yellow disconnected banner, but will have another banner if connecting -> connected transition takes long that will say "catching up" or something of that line, but that is clear to the users that their changes are not being saved to service yet.
3. I do not know if we want to do it in the same round, but I find naming (especially on Container misleading). The underlying semantics and what names project are not one and the same and some renaming is required in the vein:
   • Connecting, connect -> (socket) connected
   • connected -> caught up, saving changes

[vladsud]

See old threads on same subject: #1839
Note that we do have checkpointSequenceNumber that we did not have before (when that issue was opened) to indicate roughly how far client is behind. That said, R11s does not supply it today - code works the same, but it will not wait for catch up (i.e. after proposed above changes, behavior for R11s will not change, and r11s / FRS will need to consider providing that info to improve user experience).

[markfields]

Moving to Jan due to my constraints in Dec with OCE and holidays. On my mind though as I'm working with Office Fluid team on connection API/health metrics.

[markfields]

Unless this is directly related to recent problems with visual op replay, I'd like to move to Feb. @vladsud let's discuss next week.

[markfields]

I'm gearing up to work on the parent epic #7995 in March, moving this hear for now to get incorporated into that planning.

[markfields]

Tracking via AB#144