Alternative approach to propagate disconnected reason during 'disconnected' event

[vivekmogalapalli]

Description

The container emits a disconnected event in event of a connection loss but it doesn't emit any additional details about why the connection was disconnected. This information is already available in the container in the form of reason and is also logged in Fluid Framework's telemetry but isn't accessible to the host that integrates with the Fluid Framework.

This change propagates reason when a disconnected event is raised by the container.

Reviewer Guidance

This is an alternative and simpler approach to Pull Request: Propagate disconnected reason during 'disconnected' event

Does this introduce a breaking change?

No

Other information or known dependencies

• The Microsoft Loop team is relying on this change to measure and improve connectivity reliability across Microsoft Loop experiences
• The next steps here would be to instrument in the host experience cases where we don't restore connection within an appropriate time and keep track of the disconnected reason that contribute to the loss of connection

[msfluid-bot]

⯅ @fluid-example/bundle-size-tests: +21 Bytes

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	387.49 KB	387.49 KB	⯅ +4 Bytes
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	191.6 KB	191.61 KB	⯅ +9 Bytes
loader.js	151.52 KB	151.53 KB	⯅ +8 Bytes
map.js	42.67 KB	42.67 KB	■ No change
matrix.js	127.15 KB	127.15 KB	■ No change
odspDriver.js	149.26 KB	149.26 KB	■ No change
odspPrefetchSnapshot.js	38.31 KB	38.31 KB	■ No change
sharedString.js	147.79 KB	147.79 KB	■ No change
Total Size	1.24 MB	1.24 MB	⯅ +21 Bytes

---

Baseline commit: 38d97ef28e919b42579a3b897f70a7060b599275

Generated by :no_entry_sign: dangerJS against cdb4be1d6d877daf5521258560e6eccb0630d776

[vivekmogalapalli]

Thanks for the feedback, Mark! There has been some refactoring to the area since, so abandoning this PR in favor of https://github.com/microsoft/FluidFramework/pull/12237