BF-45277 — read_pref_cmd.js: profile entry lost on a lagged secondary after dropDatabase/re-create

Mechanism. The test loops: setUp() → testCursorReadPreference() / testConnReadPreference() → tearDown(). tearDown() drops read_pref_cmd and waits for replication; the next setUp() re-creates the database via enableSharding + shardCollection on the primary. Those are majority writes, so in a 3-node set they return as soon as the primary and one secondary ack — the third node can still be behind.

The test then issues a read with read preference secondary and verifies routing by scanning system.profile on every node, expecting exactly one hit. If the lagged secondary is the one the read preference picks, it has applied the dropDatabase but not yet the re-create, so the database doesn't exist locally when the read arrives. The profiler discards the entry rather than writing it ("not profiling because db went away"), getNumNodesCmdRanOn() returns 0, and assert.eq(..., 1) fails.

Note the failure is a missing profile entry, not a failed command — the read itself succeeds. Enabling profiling is unaffected by the lag, since setProfilingLevel is node-local and unreplicated.

Fix. rst.awaitReplication() in setUp(), after the enableSharding/shardCollection writes and before the test body reads, so every secondary has the re-created database before any profiled read can land on it. Placed before the node loop; the loop itself replicates nothing, so its position relative to the barrier doesn't matter for correctness.