Backoffs/handlng when encountering WrongExpectedVersionException for EventStore

[bartelink]

While #19 improved the correctness of conflict handling, and according to the discussion in https://github.com/EventStore/EventStore/issues/1652 it should all be rosy, at present, a core dependent system adds an exponential backoff delay.

Fixing this in full in Equinox as a whole means:

• Ensuring we have a solution for Cosmos (see https://github.com/jet/equinox/issues/21)
• Having an optimal solution for EventStore (see https://github.com/EventStore/EventStore/issues/1652)

The interim solution for now will involve duplicating that backoff here

[bartelink]

~The Equinox.Templates template for dotnet new will likely gain a backoff function for read/append retries. When that's done, including wiring for putting the backoff into resync will likely make sense too~

The backoff computation logic is in https://github.com/jet/equinox/blob/8d44e38eeccbc3bf9ccd1d28892d14a50a36a66a/samples/Store/Domain/Retries.fs#L35

The backoff/retry logic itself is in https://github.com/jet/equinox/blob/8d44e38eeccbc3bf9ccd1d28892d14a50a36a66a/src/Equinox.Core/Retry.fs

[bartelink]

Closing as a) the twin connection workaround was implemented and works for ESDB (Though ideally they'd get around to implementing AppendOrResync b) DDB already had reread from master semantics and can now lean on the Jul 2023 adding of the ability to return the conflicting item in https://stackoverflow.com/a/76609239/11635 c) The Cosmos stored proc always returned the conflicting data d) other stores such as MessageDb request a re-read from the leader as a separated roundtrip