The 'operation_context' structure was being created twice, once as part
of lane initialization, and once as part of the recovery operation.
The first context is used for all operations, whereas the second context
lives only for the duration of the undo log recovery.

The problem was that the recovery process can change the persistent
state in such a way that the context runtime information becomes stale.
This is perfectly fine, and it's handled for the operation that
does the recovery - but at the same time, this makes the data of the
lane context invalid.

This bug was triggering ASSERTs in debug builds and might have led to
NULL dereference on release builds. Fortunately the crash happens
after recovery has been finished and simply restarting the application
gets rid of the problem.

The fix is quite simple: instead of duplicating the runtime state for
the purpose of recovery, simply use the one that already exists in the
lane.