Various shard split tests currently use initiateWithShortElectionTimeout and do not actually need it. The use of this flag can trigger frequent elections on an artificially/unrealistically short timeout that can cause shard split tests to be aborted. This isn't buying us anything in terms of correctness/resiliency testing.

An earlier work-in-progress incarnation of shard split seems to have relied on election timeouts to step up a primary on the recipient cluster after a split. As such, initiateWithShortElectionTimeout was introduced to speed up some shard split tests. Now that shard split uses replSetStepUp to request that a recipient primary steps up after reconfig, this short election timeout is no longer necessary. Additionally, evergreen sets electionTimeoutMillis to 24 hours (86400000 ms) to avoid unnecessary elections, so we can safely use the default for shard split.