Consider retrying commits when CAS is slow at the database level

[dimas-b]

Issue description

Nessie can use retries at the database client level (e.g. with Bigtable) for normal reads.

However, when committing CAS operations (e.g. CheckAndMutateRow in Bigtable) are not idempotent and normally will not retry at the database client level.

Still, Nessie itself can re-attempt the whole commit when the CAS operation is slower than normal. The overhead of rebuilding the commit state is probably negligible in cases when the whole database communication channel slows down.

[snazy]

Looks like this would be fixed via #8533