fast-forward spends can be treated as regular spends

[arvidn]

if the coin doesn't appear to support the rebasing

Purpose:

In #19713 we introduced the optimization of using spent_index = -1 to indicate whether a coin's parent has the same puzzle hash and amount. When accepting a FF spend into the mempool, we need to ensure that it will be possible to rebase it on top of the latest version (otherwise the mempool may have invalid spends in it, wasting space).

In #19272, any spend submitted to the mempool, that supports fast forward, is checked that the coin it's spending has spent_index = -1. If not, the spend is rejected as DOUBLE_SPEND.

There's a problem with migration, since older nodes will have just left the spent_index = 0, even if coins support fast forward. Attempting to submit a FF spend to a new node with an old database will fail with this error.

This patch, instead, turns the spend into a normal spend. Not marking it as eligible for FF means the coin it's spending actually have to be unspent. This solves the transition problem as long as only one spend at a time happens first.

i.e. in the scenario of a new node with an old database, only a single FF spend will go through at first. Once the FF singleton has been spent once, FF will be fully enabled, since the new coin will have spent_index = -1 set in the node's database.

Current Behavior:

New Behavior:

Testing Notes:

[wjblanke]

aok