[seekdb][transaction] Retry GTS acquisition when not ready

[hnwyllmm]

Task Description

When the local GTS service has not prepared the next timestamp range, ObTsMgr::get_gts returns OB_EAGAIN. The snapshot acquisition path did not distinguish this temporary GTS state from generic OB_EAGAIN, so the error could escape the transaction layer and become a user-visible JDBC Try again during write pressure.
The original bigtrans_lite incident also contains PALF-side OB_EAGAIN. This change is intentionally limited to the GTS snapshot path and does not claim to retry or mask every PALF OB_EAGAIN source.

Solution Description

• Restore OB_GTS_NOT_READY when nonblocking GTS acquisition returns OB_EAGAIN.
• Retry GTS acquisition internally with a 10 ms interval, for at most 1 second and no later than the request or transaction deadline.
• Release the transaction descriptor lock while synchronously waiting, then recheck interruption, abort, rollback and operation-sequence state after reacquiring it.
• Use the retrying snapshot path for transaction read snapshots, write-store-context snapshots and snapshot-version acquisition.
• Treat ID-not-ready errors as retryable in the existing MDS registration retry loop.

Passed Regressions

• git diff --check
• CARGO_NET_OFFLINE=true ob-make seekdb (release build, compile and link passed)
  The original CI endpoint had already been cleaned up, so the full bigtrans_lite workload was not replayed in this change.

Upgrade Compatibility

No storage format, schema, wire protocol or configuration change. This only changes transaction-layer error classification and bounded retry behavior.

Other Information

• MR contains one commit: 74e0e0b966e.
• GTS polling interval is 10 ms; the bounded wait does not introduce an unbounded SQL retry.
• Generic PALF OB_EAGAIN handling remains outside this MR.
• Related links: DIMA-2026081800118330224

Release Note

[hnwyllmm]

The mapping Dima issue is that during bulk writes to wide tables, PALF/transaction logs continuously return error -4023, causing JDBC to receive a "Try again" message and resulting in UpdateIgnore initialization failure.