Timeout exceptions are unable to be grouped due to variables not being in quotes or parentheses

The general accepted behaviour in a well written Exception in .net seems to be to enclose parameters in []. This allows logging frameworks to extract the variables and group identical messages togehter.

A common example of this is the DataDog platform that tries to group the same exception for issue tracking.

The StackExchange.Redis library breaks this capability by including a large number of parameters in the Timeout (and other exceptions I suspect), but without encapsulating the parameters, leading to 1000s of unique errors/issues.

For example the exception in #3029 is currently:
Timeout awaiting response (outbound=0KiB, inbound=0KiB, 6500ms elapsed, timeout is 5000ms), command=GET, next: SET 2700758, inst: 0, qu: 0, qs: 0, aw: False, bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 371, last-in: 2, cur-in: 0, sync-ops: 1, async-ops: 363, serverEndpoint: 20.198.145.151:8501, conn-sec: 80376.19, aoc: 0, mc: 1/1/0, mgr: 10 of 10 available, clientName: f1fd87ec2fb3(SE.Redis-v2.10.1.65101), PerfCounterHelperkeyHashSlot: 6029, IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=20,Free=32747,Min=2,Max=32767), POOL: (Threads=20,QueuedItems=69,CompletedItems=1218359,Timers=36), v: 2.10.1.65101 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)

But I would expect it to be:
Timeout awaiting response (outbound=[0]KiB, inbound=[0]KiB, [6500]ms elapsed, timeout is [5000]ms), command=[GET], next: [SET] [2700758], inst: [0], qu: [0], qs: [0], aw: [False], bw: [SpinningDown], rs: [ReadAsync], ws: [Idle], in: [371], last-in: [2], cur-in: [0], sync-ops: [1], async-ops: [363], serverEndpoint: [20.198.145.151:8501], conn-sec: [80376.19], aoc: [0], mc: [1/1/0], mgr: [10 of 10] available, clientName: [f1fd87ec2fb3(SE.Redis-v2.10.1.65101)], PerfCounterHelperkeyHashSlot: [6029], IOCP: (Busy=[0],Free=[1000],Min=[1],Max=[1000]), WORKER: (Busy=[20],Free=[32747],Min=[2],Max=[32767]), POOL: (Threads=[20],QueuedItems=[69],CompletedItems=[1218359],Timers=[36]), v: [2.10.1.65101] (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)

As a shortcut it would solve the problem by just wrapping all the data in a single pair of [], but that doesn't feel like in-keeping with .net Exception guidelines:

Timeout awaiting response [(outbound=0KiB, inbound=0KiB, 6500ms elapsed, timeout is 5000ms), command=GET, next: SET 2700758, inst: 0, qu: 0, qs: 0, aw: False, bw: SpinningDown, rs: ReadAsync, ws: Idle, in: 371, last-in: 2, cur-in: 0, sync-ops: 1, async-ops: 363, serverEndpoint: 20.198.145.151:8501, conn-sec: 80376.19, aoc: 0, mc: 1/1/0, mgr: 10 of 10 available, clientName: f1fd87ec2fb3(SE.Redis-v2.10.1.65101), PerfCounterHelperkeyHashSlot: 6029, IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=20,Free=32747,Min=2,Max=32767), POOL: (Threads=20,QueuedItems=69,CompletedItems=1218359,Timers=36), v: 2.10.1.65101 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)]

Start by locating the timeout-exception message construction and any related exception-formatting paths in the repository, then reproduce the sample output from the issue. Done means variable values are consistently delimited for grouping while the exception remains readable, with coverage for the resulting formatting.