When a standby steps up, it needs to copy the content from the stable table to the ingest table. If a key has been prepared (either committed or rolled back now) and the prepared timestamp is stable but the durable timestamp or rollback timestamp is not stable, we must have written a prepared update to the stable table. In this case, during the draining process, we need to resolve this prepared update on the stable table. Otherwise, we will have a prepared update never resolved on the stable table.

When we resolve the prepared update in this case, we don't have the transaction structure which is required to resolve the prepared update when the transaction is committed. Therefore, it is better for us to first refactor the prepared resolve code to pass all the information to the prepare resolve function instead of having the function to rely on session specific information like the transaction. In this way, we can share the same logic when resolving the prepared updates during the draining process with prepared resolving in transaction commit/rollback.