first pass at a refactoring to clean up the hardcoded ports – takes advantage of the copyFile function that was already in the test to replace a marker token in the config with the real port number.
at first glance this refactoring should work, but testIndexAndConfigAliasReplication errors with this patch --i believe the problem is because it expects the slave to pull files from a master after the master server has been stoped and then restarted – which fails because the new master won't have the same port number. we could try explicitly creating the new master with the same port as the old master, but there's no guarantee the os won't have already allocated that port to a new process at that point. A better solution is to eliminate the need to stop/start the master by using core reload or something similar instead.
The most alarming thing at this point is that several other test methods do similar stop/start of the master, and yet they work fine (even though the slave has no knowledge of the new master port) which suggests to me that the tests may be false positives making flawed assumptions.
unfortunately i don't have any more time to look into this at the moment ... attaching patch as a checkpoint in case someone else wants to look into it (or i get hit by a bus)