feat: use exponential retry strategy

[vlastahajek]

Proposed Changes

This PR aligns retry strategy implementations across all official InfluxDB client libraries so that a delay for the next retry delay is a random value in the interval retryInterval * exponentialBase^(attempts) and retryInterval * exponentialBase^(attempts+1).
The defaults were changed:

• retryInterval=5_000
• exponentialBase=2 (it is now also configurable)
• maxRetryDelay=125_000
• maxRetries=5

Retry delays are by default randomly distributed within the ranges of [5_000-10_000, 10_000-20_000, 20_000-40_000, 40_000-80_000, 80_000-125_000].

Added is also MaxRetryTime option. When an overall time spent by retrying exceeds a maxRetryTime (180_000 millis by default), the write is not retried and fails.

Checklist

• CHANGELOG.md updated
• Rebased/mergeable
• A test has been added if appropriate
• Tests pass
• Commit messages are in semantic format

[sranka]

I didn't find a test herein that proves that it is a maximum retry time since the first retry attempt ... is it really so?

[vlastahajek]

This line is intended to test that.

[sranka]

This is IMHO testing maxRetryInterval, I was looking for a test (or proof) that maxRetryTime works.

[vlastahajek]

Oh, sorry, this test should test that

[sranka]

The test is really difficult to understand as it is not obvious that a second srv.HandleWrite is required to return an error from the previously inserted expired batch ... a comment might have helped me to understand it. Anyway, It is not clear from the code that the second WriteBatch is actually tried immediately, IMHO it is not. Higher knowledge of the execution context is required even for the test. A test that would match the user expectation is something that was looking for, simply checking that an error is signalized after maxRetryTime is reached and the expired retried item is removed from the retry queue.

[vlastahajek]

Yes, for someone unfamiliar with how the write service works this seems complicated. I added more comments to improve readability.
One thing that is not obvious, and is that retries are not scheduled to be sent automatically. Retries are triggered by new writes.

[sranka]

I was also confused by the fact that WriteBatch can fail even without trying to write the data on input. It was this way before, so it is not in the scope of this PR. Thank you for your explanation.