[seekdb][ddl] Fix DDL lock timeout propagation

[hnwyllmm]

Task Description

Online ALTER TABLE operations could cause client requests to wait indefinitely when they conflicted with concurrent online DDL locks. This occurred because the DDL lock layer passed timeout_us = 0 to table lock requests. However, the table lock code interprets 0 with mixed semantics: sometimes as a try-lock, and in other code paths, it expands to the table-lock service's default timeout, leading to unbounded waits.

Solution Description

The fix ensures the DDL lock request uses a bounded timeout. It propagates the current worker's remaining timeout to the DDL lock request, using _ob_ddl_timeout as a fallback when the worker has no deadline. This prevents passing timeout_us = 0 into table lock requests, thereby bounding the DDL lock wait by the active DDL request's timeout. Additionally, the error OB_ERR_EXCLUSIVE_LOCK_CONFLICT is now classified as a retryable table-lock error for DDL normalization paths.

Passed Regressions

git diff --check

Upgrade Compatibility

No upgrade compatibility impact. The change only affects DDL lock wait timeout propagation and retry error normalization.

Other Information

• Fixed branches: master
• MR contains one commit: 231a95b0495 fix ddl lock timeout propagation
• Local untracked files issue.md and 2 are not included in the MR.
• Related internal link: DIMA-2026070200117135230

Release Note

Fixed an issue where online ALTER TABLE operations could wait indefinitely due to DDL lock timeout mispropagation. DDL lock waits are now correctly bounded by the request's timeout.

[hnwyllmm]

The mapping Dima issue is [seekdb][obsplit_lite] Client times out with 'Lost connection (2013)' after running an online column modification on bmsql_district for about 20 minutes