The dist lock manager used on the config server does read concern 'majority' reads against the instance on which it is running.

While this is not a correctness problem, it may cause deadlock when used from internal threads, because locally done reads do not obey the operation deadline when waiting for RC majority and also because internal threads are not interrupted on step down.

This is evidenced by a deadlock on balancer shutdown with the following order of events:

1. Node becomes primary and balancer thread is started
2. Node steps down just before the balancer thread manages to wait for RC majority as part of the balancer dist lock overtake
3. Node steps down, but balancer thread continues to wait for majority RC

Left in the state above, that node cannot become primary again, without ever becoming secondary, because the balancer thread is stuck.