Experiment with long polling in ODSP driver

[vladsud]

This issue is result of us learning that some tenants might be blocking websocket connections by inspecting traffic (going through their proxies) and disabling websocket upgrade of http connection by dropping some headers.

In such case the product fails by showing disconnected banner and losing user local changes.

It would be great to better understand

• how we can reliable identify such cases, and possibly fail with unique error code allowing hosts to show detailed error message to the user (possibly by validating that we could connect to relay service using long polling).
• potentially use long polling (built into socket.io library as one of the protocols) as a fallback.
  • Need to better understand impact on client and server, i.e. drop in latencies and CPU impact on relay service.

One important thing to note is that if both websocket and long-polling protocols are enabled, socket.io will use long-polling as a first protocol. That's likely not what we want, so the flow should be - attempt to connect via websocket protocol, and if it fails - fall back to long-polling.

It would likely look similar to how AFD fallback looked like before (PR #5987 can be used to look into old structure).

Here is where we encode transport:

FluidFramework/packages/drivers/odsp-driver/src/odspDocumentDeltaConnection.ts

Line 320 in 3b9de8c

transports: ["websocket"],

Useful article to look into: https://socket.io/docs/v3/how-it-works/#upgrade-mechanism

[vladsud]

See #8820 for addition of capability on client side.

[microsoft-github-policy-service]

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