Confirm retry behaviour when a WriteTimeoutException occurs for Collections

[amorton]

we worked out that the WritetimeoutException is coming back as a WriteType SIMPLE when it fails in the COMMIT phase of the Paxos Tx for collections. We are confirming this with extra logging, if true the retry for collections should work for any write timeout (so not need to check the write type).

Original desc is below...

---

Confirm what happens in the API when running a write operation for a Collection and a WriteTimeoutException is returned from the DB.

It may be returning the timeout to the client without retrying, we should review if this is the best and if we can retry the request

[amorton]

discussions - also check what retry policy the tables are using. It would be good to have the same retry policy is possible, which would mean removing the test for the write type.

note - we also discussed refactoring the try policy class so:

• derives from DefaultRetryPolicy
• does not override default methods from the RetryPolicy interface
• has better logging that always logs the decisions, and maybe logs a rethrow decision at WARN