[CURATOR-601] TestingCluster Threads leak with Zk 3.6.X

We are testing Curator 5.1.0 with ZK 3.6.0 to 3.6.3 and found out our test cases are failing due to VM Crashing (Which is not happening with ZK 3.5.X). After further investigation, it seems some threads are being leaked after each test executed.

We are using TestingClusters of 1 and 3 members in this tests 

After a single test of using 3 TestingCluster we can see this threads still alive:

Threads after test is finished

Active Threads: 14

0: Thread[main,5,main]

1: Thread[Monitor Ctrl-Break,5,main]

2: Thread[Log4j2-TF-2-Scheduled-1,5,main]

3: Session Sets (0)/(0):4: Thread[WorkerSender[myid=2],5,main]

5: Thread[WorkerSender[myid=3],5,main]

6: Thread[WorkerSender[myid=1],5,main]

7: Thread[WorkerReceiver[myid=2],5,main]

8: Thread[WorkerReceiver[myid=1],5,main]

9: Thread[WorkerReceiver[myid=3],5,main]

10: Session Sets (0)/(0):11: Session Sets (2)/(0):

0 expire at Wed Jun 30 16:53:55 CEST 2021:

0 expire at Wed Jun 30 16:53:58 CEST 2021:12: Thread[QuorumConnectionThread-[myid=2]-3,5,main]

13: Thread[QuorumConnectionThread-[myid=1]-3,5,main]

After some tests it scalates quickly to 200-300 theards that never ends until VM Crash.

---
Originally reported by mario.uso, imported from: TestingCluster Threads leak with Zk 3.6.X

• status: Open
  
• priority: Major
  
• resolution: Unresolved
  
• imported: 2025-01-20
  

Start by reproducing the leak with one- and three-member TestingCluster instances on ZooKeeper 3.6.0–3.6.3, then compare teardown behavior with ZooKeeper 3.5.x. Trace the listed WorkerSender, WorkerReceiver, and QuorumConnectionThread threads after each test; done means cluster teardown leaves no unexpected threads and repeated tests no longer drive the VM toward a crash.

Written by the indexing model from the issue text.