Fix thread leak in hive-metastore caused by thread pool per HiveTableOperations

[ghost]

Fix thread leak in hive-metastore caused by new thread pool instance created for each HiveTableOperations instance

[pvary]

Funny thing that I have found the same issue when running the spark tests against my PR: #6570.
#6570 would fix this too by recreating the hiveLockHeartbeatExecutorService for every Lock (the same way that we were doing for the HiveTableOperations before #6570).

I have some concerns about the proposed solution:

• The size of the threadpool is depends on the configuration of the first executor to call the initHiveLockHeartbeatScheduledExecutorService - this would create hard to reproduce situations and it would be hard to understand why the new iceberg.hive.lock-heartbeat-threadpool-size is "not used" in some cases
• This creates a JVM wide threadpool, and if the pool is exhausted then the heartbeating of the Lock will not happen, and it is done silently, which can cause issues later

On the plus side, we do not recreate the pool every time when there is a new HiveTableOperations/Lock

[ghost]

Yes, I have completely missed scenario with multiple hive configurations.
Great that issue is already resolved by #6570. Closing PR.

[pvary]

For the record #6570 has not been merged yet.
I was not clear enough, sorry for that