We now store the meta data needed for a portal's re-execution in PreparedPortal.portalPauseInfo. This field includes things such as instrumentationHelper and planTop which are to override the planner for each execution. But this can be error-prone and confusing as now we reset most of the fields of a planner, even though the underlying query is the same.

One more bullet-proof approach would be to embed planner object into the pause info struct, and then use that planner instance whenever we're operating with the pausable portals. pauseInfo.planner would be modified ("initialized") on the first execution of the portal, but then we will not call resetPlanner() on it. This way, with every re-execution we will let the resumed flow to modify our planner as the flow needs, and then we'll keep the state of the planner unchanged until the portal is resumed again. This approach will also let us remove fields like portal.pauseInfo.ihWrapper.

The key here is to determine what in planner should be retained and what should be updated for each execution.

Jira issue: CRDB-25987

Epic CRDB-25183