We currently spin up sharding in advance of replication (see SERVER-41005). Because of that, it is possible for sharding to miss out on certain writes on startup (writes to admin.system.version that are still in the oplog and haven't yet been recovered).

It's going to be quite difficult to untangle all the dependencies between sharding and replication, and in the mean while shard_aware_init has more failures than we'd like. See BF-12759. That particular test specifically checks that corrupting our version (via a manual update to admin.system.version) causes mongod to crash on startup. The problem is that because we start sharding before replication (and also do a complicated dance of restarting in standalone mode to corrupt the document), we can perform an update when the document we want to modify isn't present (because it's still in the oplog and we're in standalone mode), and then fail to crash on startup.

So let's fix up that test by waiting to flush the oplog before shutting down the node (when in replica set mode).