The recover_prepared_txn_with_multikey_write.js test reconstructs a prepared transaction that did a multikey write. After reconstructing this transaction, we should assert that no prepare conflicts are generated on the catalog, to make sure that the transaction was reconstructed correctly and the multikey write was done in a side transaction. This may have helped catch the issue referenced in SERVER-42750. We should also make sure it waits for the restarted node to become primary again, so that data consistency checks are not skipped inside stopSet. Furthermore, it should abort the prepared transaction before shutting down the set.