35777: rangefeed: don't discard ref count for txn after intent abort r=nvanbenschoten a=nvanbenschoten

Fixes #34600.

Before this commit, rangefeed made the assumption that an aborted intent
implied an aborted transaction (after the rangefeed was in a steady-state).
It used this assumption to eagerly discard the bookkeeping for a transaction
after its first MVCCAbortIntent operation was seen as an optimization.

This was incorrect. A transaction can "abort" an intent even if it commits.
This is possible if the intent was only written at a previous epoch and not
written in the epoch that ended up finalizing the transaction. This commit
removes this assumption, which I confirmed fixes the resolved timestamp
regression using the new assertion from #35772.

I believe this could have two effects:
- it could trigger the assertion failure from #34600 if the transaction
  experiencing the incorrect assumption was the oldest being tracked at
  the time of the assumption.
- it could cause resolved timestamp stalls and prevent all future forward
  progress of resolved timestamps if the transaction experiencing the incorrect
  assumption was not the oldest being tracked at the time of the assumption.

Release note: None

Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>

Fixes cockroachdb#35816.

The fix in cockroachdb#35777 inadvertently broke `txnPushAttempt` and its interaction with
transactions that were found to be aborted. This commit restores this handling
by reverting part of the assertion added in cockroachdb#35772 and splitting up the handling
of "aborted intents" from the handling of "aborted transactions".

Aborted transactions were always one of the most tricky situations to handle in
rangefeed. The challenge is that rangefeed may be tracking a transaction that
has been abandoned and may want to push it to unblock its resolved timestamp,
but it doesn't have a way to know where the aborted transaction's intents live
on its range. The aborted transaction record can't tell us this either. So the
only thing rangefeed can do is push the transaction and convince itself that the
aborted intents on its range can be safely ignored. This poses a problem for
accurate reference counting of intents though. We need to be able to discard a
transaction and still handle the eventual resolution of its aborted intents.

To handle this properly, the change splits up `MVCCAbortIntentOp` into
`MVCCAbortIntentOp` and `MVCCAbortTxnOp`. Before this change, the single
operation type was attempting to fill both roles, but they mean fundamentally
different things. `MVCCAbortTxnOp` is then given back its ability to delete
transactions from the queue directly without worrying about their reference
count. Next, the `unresolvedIntentQueue` is extended to be a little more
flexible. Instead of asserting that reference counts never drop below zero, it just
ignores changes that would make reference counts negative. This has the potential
to "leak" reference counts that saturate at zero and are then incremented again,
but we know that this will only ever happen for aborted transactions, which can
always be pushed again to rediscover that they have been aborted.

Release note: None

Fixes cockroachdb#35816.

The fix in cockroachdb#35777 inadvertently broke `txnPushAttempt` and its interaction with
transactions that were found to be aborted. This commit restores this handling
by reverting part of the assertion added in cockroachdb#35772 and splitting up the handling
of "aborted intents" from the handling of "aborted transactions".

Aborted transactions were always one of the most tricky situations to handle in
rangefeed. The challenge is that rangefeed may be tracking a transaction that
has been abandoned and may want to push it to unblock its resolved timestamp,
but it doesn't have a way to know where the aborted transaction's intents live
on its range. The aborted transaction record can't tell us this either. So the
only thing rangefeed can do is push the transaction and convince itself that the
aborted intents on its range can be safely ignored. This poses a problem for
accurate reference counting of intents though. We need to be able to discard a
transaction and still handle the eventual resolution of its aborted intents.

To handle this properly, the change splits up `MVCCAbortIntentOp` into
`MVCCAbortIntentOp` and `MVCCAbortTxnOp`. Before this change, the single
operation type was attempting to fill both roles, but they mean fundamentally
different things. `MVCCAbortTxnOp` is then given back its ability to delete
transactions from the queue directly without worrying about their reference
count. Next, the `unresolvedIntentQueue` is extended to be a little more
flexible. Instead of asserting that reference counts never drop below zero, it just
ignores changes that would make reference counts negative. This has the potential
to "leak" reference counts that saturate at zero and are then incremented again,
but we know that this will only ever happen for aborted transactions, which can
always be pushed again to rediscover that they have been aborted.

Release note: None

Fixes cockroachdb#35816.

The fix in cockroachdb#35777 inadvertently broke `txnPushAttempt` and its interaction with
transactions that were found to be aborted. This commit restores this handling
by reverting part of the assertion added in cockroachdb#35772 and splitting up the handling
of "aborted intents" from the handling of "aborted transactions".

Aborted transactions were always one of the most tricky situations to handle in
rangefeed. The challenge is that rangefeed may be tracking a transaction that
has been abandoned and may want to push it to unblock its resolved timestamp,
but it doesn't have a way to know where the aborted transaction's intents live
on its range. The aborted transaction record can't tell us this either. So the
only thing rangefeed can do is push the transaction and convince itself that the
aborted intents on its range can be safely ignored. This poses a problem for
accurate reference counting of intents though. We need to be able to discard a
transaction and still handle the eventual resolution of its aborted intents.

To handle this properly, the change splits up `MVCCAbortIntentOp` into
`MVCCAbortIntentOp` and `MVCCAbortTxnOp`. Before this change, the single
operation type was attempting to fill both roles, but they mean fundamentally
different things. `MVCCAbortTxnOp` is then given back its ability to delete
transactions from the queue directly without worrying about their reference
count. Next, the `unresolvedIntentQueue` is extended to be a little more
flexible. Instead of asserting that reference counts never drop below zero, it just
ignores changes that would make reference counts negative. This has the potential
to "leak" reference counts that saturate at zero and are then incremented again,
but we know that this will only ever happen for aborted transactions, which can
always be pushed again to rediscover that they have been aborted.

Release note: None

35889: rangefeed: fix handling of aborted transactions found by txnPushAttempt r=nvanbenschoten a=nvanbenschoten

Fixes #35816.

The fix in #35777 inadvertently broke `txnPushAttempt` and its interaction with
transactions that were found to be aborted. This commit restores this handling
by reverting part of the assertion added in #35772 and splitting up the handling
of "aborted intents" from the handling of "aborted transactions".

Aborted transactions were always one of the most tricky situations to handle in
rangefeed. The challenge is that rangefeed may be tracking a transaction that
has been abandoned and may want to push it to unblock its resolved timestamp,
but it doesn't have a way to know where the aborted transaction's intents live
on its range. The aborted transaction record can't tell us this either. So the
only thing rangefeed can do is push the transaction and convince itself that the
aborted intents on its range can be safely ignored. This poses a problem for
accurate reference counting of intents though. We need to be able to discard a
transaction and still handle the eventual resolution of its aborted intents.

To handle this properly, the change splits up `MVCCAbortIntentOp` into
`MVCCAbortIntentOp` and `MVCCAbortTxnOp`. Before this change, the single
operation type was attempting to fill both roles, but they mean fundamentally
different things. `MVCCAbortTxnOp` is then given back its ability to delete
transactions from the queue directly without worrying about their reference
count. Next, the `unresolvedIntentQueue` is extended to be a little more
flexible. Instead of asserting that reference counts never drop below zero, it just
ignores changes that would make reference counts negative. This has the potential
to "leak" reference counts that saturate at zero and are then incremented again,
but we know that this will only ever happen for aborted transactions, which can
always be pushed again to rediscover that they have been aborted.

Release note: None

Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>

Fixes cockroachdb#35816.

The fix in cockroachdb#35777 inadvertently broke `txnPushAttempt` and its interaction with
transactions that were found to be aborted. This commit restores this handling
by reverting part of the assertion added in cockroachdb#35772 and splitting up the handling
of "aborted intents" from the handling of "aborted transactions".

Aborted transactions were always one of the most tricky situations to handle in
rangefeed. The challenge is that rangefeed may be tracking a transaction that
has been abandoned and may want to push it to unblock its resolved timestamp,
but it doesn't have a way to know where the aborted transaction's intents live
on its range. The aborted transaction record can't tell us this either. So the
only thing rangefeed can do is push the transaction and convince itself that the
aborted intents on its range can be safely ignored. This poses a problem for
accurate reference counting of intents though. We need to be able to discard a
transaction and still handle the eventual resolution of its aborted intents.

To handle this properly, the change splits up `MVCCAbortIntentOp` into
`MVCCAbortIntentOp` and `MVCCAbortTxnOp`. Before this change, the single
operation type was attempting to fill both roles, but they mean fundamentally
different things. `MVCCAbortTxnOp` is then given back its ability to delete
transactions from the queue directly without worrying about their reference
count. Next, the `unresolvedIntentQueue` is extended to be a little more
flexible. Instead of asserting that reference counts never drop below zero, it just
ignores changes that would make reference counts negative. This has the potential
to "leak" reference counts that saturate at zero and are then incremented again,
but we know that this will only ever happen for aborted transactions, which can
always be pushed again to rediscover that they have been aborted.

Release note: None