[CBRD-26478] Refactor lock manager initialization

[hgryoo]

http://jira.cubrid.org/browse/CBRD-26478

Purpose

This change refactors lock_manager initialization/finalization to centralize runtime configuration and make lock-manager-owned resources explicit.

• Initialization defaults and derived sizing logic are now managed in one place.
• Resource ownership and cleanup order are clearer.
• The refactor reduces coupling between initialization code and global state layout without intending behavioral changes under default settings.

Implementation

• Consolidated initialization parameters and derived runtime values into an internal lock-manager config.
• Replaced scattered globals such as transaction count, object lock sizing, verbose mode, and dump level with config-backed values.
• Merged object lock hash-table and freelist setup into a single initialization path.
• Split cleanup into dedicated finalization steps for:
  • transaction lock table
  • object lock structures
  • deadlock detection resources
• Replaced fixed deadlock-related storage with lock-manager-owned dynamic allocations:
  • TWFG_edge_storage
  • victims
• Made deadlock daemon teardown safer by nulling the daemon pointer after destroy.
• Kept the config-based initialization path internal; no new public lock-manager API is exposed by this refactor.

Remarks

N/A

[github-actions]

🧪 TC Test Environment Ready

CircleCI Testing:

• CircleCI will automatically test using the branches below.

TC Repositories & Branches:

• cubrid-testcases Draft PR (Branch: tc/pr-6930)
• cubrid-testcases-private-ex Draft PR (Branch: tc/pr-6930)

Next Steps:

1. Wait for CircleCI tests to complete
2. If CircleCI tests failed, please check the test results and fix the issues.
3. When ready to merge this PR, please merge the TC PR first, then merge this PR.

[hgryoo]

/run all

[greptile-apps]

_{Reviews (1): Last reviewed commit: "indent, fix build" | Re-trigger Greptile}

[greptile-apps]

_{Reviews (2): Last reviewed commit: "apply review by greptile" | Re-trigger Greptile}

[greptile-apps]

_{Reviews (3): Last reviewed commit: "fix finalizing order" | Re-trigger Greptile}

[greptile-apps]

pthread_mutex_destroy — lock_initialize_deadlock_detection 미호출 경로에서 무조건 실행

lock_finalize_deadlock_detection은 항상 pthread_mutex_destroy(&lk_Gl.DL_detection_mutex)를 호출합니다. 그런데 DL_detection_mutex의 pthread_mutex_init 호출은 lock_initialize_deadlock_detection 내부(line 1292)에서만 이뤄집니다.

문제 시나리오: lock_initialize_with_config에서 lock_initialize_tran_lock_table 또는 lock_initialize_object_lock_structures가 실패하면 → goto error → lock_finalize() → lock_finalize_deadlock_detection() 순서로 호출됩니다. 이 경우 lock_initialize_deadlock_detection은 한 번도 호출되지 않았으므로 DL_detection_mutex는 구조체 생성자의 PTHREAD_MUTEX_INITIALIZER로만 초기화된 상태입니다.

Linux/glibc에서는 PTHREAD_MUTEX_INITIALIZER 상태의 뮤텍스에 대해 pthread_mutex_destroy를 호출해도 안전하지만, POSIX 표준 상으로는 "명시적으로 초기화된(via pthread_mutex_init) 뮤텍스"에만 destroy를 보장합니다. 이식성 측면에서 간단한 guard 조건을 추가하는 것을 권장합니다.

/* lock_finalize_deadlock_detection 내부, 현재 마지막 라인 직전에 조건 추가 */
if (lk_Gl.TWFG_node != NULL || lk_Gl.TWFG_edge_storage != NULL)
  {
    /* DL_detection_mutex was pthread_mutex_init'd only if lock_initialize_deadlock_detection ran */
    pthread_mutex_destroy (&lk_Gl.DL_detection_mutex);
  }

또는 LK_GLOBAL_DATA에 bool deadlock_detection_initialized 같은 플래그를 두고 lock_initialize_deadlock_detection 진입 시 설정하는 방식으로 명확히 할 수 있습니다.