Use a dedicated pub/sub connection under RESP3 by default

[mgravell]

Fixes #3263.

Problem

Redis classifies any connection with a live subscription as a pub/sub client (flags=P), and applies the pubsub class of client-output-buffer-limit to it - 32mb 8mb 60 by default, against no limit for normal clients. #3255 (unreleased) correctly subscribed the configuration channel under RESP3, but because RESP3 shared the interactive connection with pub/sub, that made every RESP3 interactive connection a pub/sub client. A single large reply, a large MGET/HGETALL, or a burst of pipelined replies then gets the connection closed by the server, failing every in-flight command. This was never specific to the config channel: any RESP3 user who subscribed to anything was exposed; #3255 just made it the default.

Measured against Redis 8.9 with default limits:

connection	flags	GET 40MiB value
RESP2, unsubscribed	N	ok
RESP3, unsubscribed	N	ok
RESP3 + SUBSCRIBE	P	closed by server, 0 bytes
RESP3 SUBSCRIBE then UNSUBSCRIBE	N	ok

The whole reply is checked against the hard limit before it is written, so MGET of a 64KiB value ~600 times reproduces it just as well.

Change

• New ConfigurationOptions.SharedSubscriptionConnection / sharedSubscriptionConnection= (also on DefaultOptionsProvider), default false. Under RESP3, pub/sub now uses a dedicated connection (negotiating RESP3 itself), exactly as under RESP2; sharing the interactive connection is opt-in. No effect under RESP2. No provider overrides the default.
• Routing goes through ServerEndPoint.SharesSubscriptionConnection() instead of KnowOrAssumeResp3(); with sharing off, routing no longer depends on the pre-handshake protocol guess at all. Connect monitors wait for the second leg unless shared.
• Fixed a double QUIT to the shared connection on close (Close(Subscription) resolved to the interactive bridge).
• Docs: Resp3.md (new "Pub/sub connections" section), Configuration.md, SyncOverAsync.md - including advice to check the server's pubsub limits against the largest replies/pipelined bursts before opting in.

Tests

• Connection-shape tests now run in both modes rather than assuming RESP3 = one connection.
• New PubSubOutputBufferTests: reads the server's pubsub hard limit (skips if unavailable), subscribes, then MGETs past it; dedicated connection survives and stays Normal, shared RESP3 connection is killed. No server config change, so it can run in parallel.
• MaintenanceNotificationTests: four exact delivery counts relaxed to > 0, since the test server's SendRawPush(null, ...) deliberately ignores opt-in and now also reaches the RESP3 subscription connection.

Full suite green on net10.0 locally; on net8.0 one unrelated timing flake (KeyIdleAsyncTests.TouchIdleTimeAsync, passes in isolation). net481 not run locally.

Release notes (for the GitHub release)

Under RESP3, pub/sub now uses a dedicated connection by default, as under RESP2, so RESP3 clients use two connections per server rather than one. Sharing a single connection caused the server to apply its (much tighter) pub/sub output-buffer limits to ordinary traffic, which could close the connection under large replies (#3263). To restore the previous single-connection behaviour, set sharedSubscriptionConnection=true - after checking that the server's client-output-buffer-limit pubsub settings suit your largest replies.