[CBRD-25754] Regression: change structure for deadlock log.

[hyahong]

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

Purpose
이슈 CBRD-25590로 인해 발생하는 오류를 제거하기 위해 구조를 변경

Implementation
CBRD-25590에서 처리한 내용은 아래와 같습니다.

1. 사용되지 않는 코드들과 처리를 제거
2. deadlock 로그 간략화
3. malloc을 사용하지 않을 수 있도록 구조 변경

deadlock을 일으킨 잠금들을 추후 출력하기 위해서 victim (LK_DEADLOCK_VICTIM)은 deadlock cycle의 정보를 저장해야 합니다.
이를 위해 holder (LK_ENTRY *)와 waiter (LK_ENTRY *)멤버를 LK_DEADLOCK_VICTIM에 추가했습니다. (holder는 현재 잠금을 얻은 entry, waiter는 holder로 인해 잠금을 대기 중인 entry를 의미)
이때 초기화가 아닌 런타임에서 malloc을 호출하는 것을 피하기 위해 잠금 구조체 LK_ENTRY의 멤버 local next을 사용하여 연결 리스트로 구성하였습니다. (local next는 claim된 상황에서는 사용에 자유롭다)

최종적으로 LK_DEADLOCK_VICTIM 내부에서 holder와 waiter는 아래처럼 걸리고, 각각 holder1, waiter1이 짝이 됩니다.
LK_ENTRY 연결 리스트
holder - holder1 - holder2 - holder3 - NULL
waiter - waiter1 - waiter2 - waiter3 - NULL

그러나 deadlock 구조 상 하나의 잠금이 여러 개의 deadlock cycle에 기여할 수 있으며, victim selection에서 선택한 트랜잭션이 여러 개의 deadlock cycle에 걸친 잠금을 가진 트랜잭션이 아닐 경우 문제가 발생합니다. 따라서
CBRD-25754에서는 연결 리스트 구조를 되돌리고 malloc을 사용하도록 변경하여 문제를 제거하였습니다.

이 경우 단순히 malloc으로 deadlock에 참여한 트랜잭션의 개수 * 2 만큼의 메모리를 할당 받고, 배열에 holder와 waiter를 번갈아가며 저장합니다.
LK_ENTRY 배열
log_trunc - false
log_num_entries - 6
log_entries - holder1 | waiter1 | holder2 | waiter2 | holder3 | waiter3

*log_trunc는 로그가 MAX_NUM_LOCKS_DUMP_TO_EVENT_LOG보다 많아 잘렸음을 의미

다만 malloc은 실패의 가능성이 존재하고, deadlock cycle 로그로 인해서 서버 전반이 다운되는 것은 과하므로 malloc을 실패할 경우 DEADLOCK이 있었다는 것만 출력하고 deadlock cycle은 출력하지 않도록 하였습니다.

Remarks
N/A