After 2 recent bugs (6736324 & 6761624) relating to ZIL replay
we thought: there must be a better way.
The problems come about because the ZIL holds a transaction
open around the call to replay the transaction. Nested transactions
are allowed but the embedded transaction is restricted to not starting
more than 2 txgs past the replay transaction. So the environment
for replay is not identical to normal non-replay transactions.
Some recent changes to remove/truncate files fell over this
restriction.
The only reason we create an replay transaction is to ensure we
replay the transaction and mark the fact that we've replayed it
atomically. Mark suggested that we remove the replay tx and increment the
log header sequence number (which marks the replay done) within the
function that normally creates the replay record (e.g. zfs_log_link()).
This takes a little bit of re-aranging but in general cleans up the
code considerably - a net deletion of code. We can remove
the two kludgy fixes for 6736324 & 6761624, plus steamline the
replay record call code. It also means we remove the strangeness where the
replay function is called twice - once with a bad txg number
to assign just to test it fails under this situation.
Any interaction between this CR and 6730441 (which the encrypted ZIL depends on).