improvement(client-presence): improve join response scalability and reliability

- In broadcast join responses:
  - include list of Client Connection Ids that the broadcast response covers. This will prevent hole where existing client sees a broadcast result too soon after a Join message and assumes it contains all sufficient and timely data.
  - potential join respondents will only reply if they have received a join response (or appear to have same or more requests that other audience members indicating complete knowledge)
- Increase trust of Audience (dictated by service) and select some of its member for named (primary) join responders when no Quorum members are known.
- Delay Join response messages for scalability
  - *Important* Do not broadcast a join response immediately even when selected as a named responder. Wait 200ms for others that may join.
- Add telemetry events for join handling:
  - `JoinDeferred` - client has chosen not to request join immediately
  - `JoinRequested` - client has broadcast Join signal
  - `JoinResponse` - client is responding to join request
  Each event includes attendee and connection ids. `JoinResponse` additionally contains lists for whom they are responding to.

Update tests for higher client counts and delayed join responses and enable previously failing test. Limit higher client count (longer duration) tests to dedicated CI pipelines.

Author: jason-ha

.changeset/floppy-sides-hammer.md

@@ -0,0 +1,7 @@
+---
+"@fluidframework/presence": minor
+"__section": feature
+---
+Improved join scalability
+
+Protocol for attendees joining has been updated to more efficiently accommodate a larger number of attendees, including when few-to-none have write access.

examples/apps/presence-tracker/tests/presenceTracker.test.ts

@@ -178,7 +178,7 @@ describe("presence-tracker", () => {
 								expected: Record<string, string>,
 							) => boolean
 						)(expectation),
-					{ timeout: 100 },
+					{ timeout: 300 },
 					expected,
 				)
 				.catch(async () => {