Two-phase upgrade/downgrade is supposed to ensure that once a node is in a "fully upgraded" FCV, then it never reads an oplog entry from the previous binary version. Committing a prepared transaction must be able to read an oplog entry behind the commit point. The Global S lock taken during upgrade/downgrade should ensure that no transactions are prepared in one FCV and committed in the other, which should prevent any problem here.

In testing upgrade/downgrade for 4.4, we should test that in committing a prepared transaction nodes do not read oplog entries generated by 4.2 binaries. Otherwise we will be unable to change the oplog format, or will need to make oplog parsing less strict, at least in this case.