This happens in cases where a txn must be logged although the operation failed.
In this case, we do not want side-effects of entries, only to increment the
next expected txn.

Table block creation can fail for a variety of reasons, but we were only
handling the happy case. This commit only overwrites the active block if the
new table block was successfully created, and logs a noop record to the WAL on
error to not block subsequent wal records logs.

Not doing so could lead to a sequence of events that could result in dropped
data:

- x is written to active block b1
- b1 is rotated, b2 becomes the active block before this has been written to
the WAL.
- A snapshot occurs of b2, the snapshot contains no data.
- A crash happens, on restart, the snapshot loads b2, an empty block.

If NewTableBlock was synchronously written in the above case, b1 would not be
overwritten by b2 until b2's creation has been synchronously written to the
WAL which can subsequently be observed in recovery. There could still be an
issue if the snapshot truncates the WAL, but that is an issue for another
commit.