ZOOKEEPER-2577: Fix flaky testDuringLeaderSync test.

[hanm]

testDuringLeaderSync uses the presence of intermediate zoo.cfg.dynamic file to decide if the reconfig operation was succeeded or not. This is not a problem and is logically correct, however in tests that provisions QuorumPeer directly through MainThread, the configFile will be null and the resulted intermediate dynamic reconfig file will has a name of "null.cfg.dynamic". This causes problem because multiple test cases use MainThread to provision QuorumPeer so these tests will share a single "null.cfg.dynamic" file, as opposed to the zoo.cfg.dynamic file in their specific test folder when configFile was not null. Since we support running concurrent ant unit tests in apache build infrastructure, it is highly likely that multiple tests that rely on this shared null.cfg.dynamic file will execute simultaneously which create all sorts of failure cases (this also explains why if one tries to reproduce the test failures in a standalone fashion the test will always pass, with the absence of the file sharing.).

This is problematic in multiple test cases and in particular cause this testDuringLeaderSync fail fairly frequently. There are multiple solutions to this problem:

• Implement retry with timeout logic when detecting the presence of intermediate config files in testDuringLeaderSync. This will fix this specific test but the fix is non-deterministic and other tests might still fail because of sharing of null.cfg.dynamic file.

• Always make sure to to feed a real config file when provision QuorumPeer. This however is an overkill as some cases a pure artificial QuorumPeer w/o real config file fit the use case well.

The approach taking here is to for this specific test, making sure we always have a configured confFileName, and it is pretty trivial to do so. For other tests, where the intermediate config file name is not important or irrelevant (e.g. FLE related tests), they will still have null confFileName because they directly provision QuorumPeer during test.

Testing done: running this patch on apache jenkins for the past week with 500 runs. Not only this test is fixed but overall stability of entirely unit tests are improved.

[shralex]

A few comments:

• It's be better if configFileName is never null. But that may be a bigger change that we don't want to do here
• If its null, it may be better to return null here and avoid calling writeDynamicConfig.
• The calling test should either initiate configFileName properly or not rely on its existance to check reconfig completion. You can do the latter by looking at the quorumVerified directly.

[hanm]

Thanks for review, Alex. I'll look into making configFileName not null for this test, which is more deterministic than a random id generator.

[hanm]

@shralex Turns out pretty trivial to guarantee a real configFileName in this case - update with one line change. Tested on apache jenkins the issue is fixed.

Note we still have configFileName as null for some other tests (such as FLE tests) but in those tests the intermediate reconfig file is not relevant so I'll just leave as they are.

[hanm]

Update pull request based on offline chat with Alex. The idea is to detect the null cases for configFileName and for those cases don't write intermediate reconfig file to disk because if we do, the shared "null.dynamic.cfg" file will be overwritten and might likely break other things without notice.