feat: various Asset Locks improvement

[knst]

What was done?

• remove dependency of Asset Lock txes on CCreditPool
• new case for functional tests of Asset Locks - more than one output for Asset Lock tx.

How Has This Been Tested?

Run unit/functional tests

Breaking Changes

Slightly changes behaviour of TxMempool. Tx can be accepted in mempool even if Asset Unlock transaction with same index is already mined. But final consensus rules are same.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

Tx can be accepted in mempool even if Asset Unlock transaction with same index is already mined.

what happens if you invalidate the block with the original tx (both the original and the duplicate one should be in mempool at that point, right?) and try to mine another block after that?

[knst]

what happens if you invalidate the block with the original tx (both the original and the duplicate one should be in mempool at that point, right?) and try to mine another block after that?

yes, both of them can be in mempool, right.
Only one of them can be mined in block.

They are validated agains creditPoolDiff here:

            if (!creditPoolDiff->ProcessTransaction(iter->GetTx(), state)) {
                if (fUsingModified) {
                    mapModifiedTx.get<ancestor_score>().erase(modit);
                    failedTx.insert(iter);
                }
                LogPrintf("%s: asset-locks tx %s skipped due %s\n",
                          __func__, iter->GetTx().GetHash().ToString(), state.ToString());
                continue;
            }

at first look it may looks like transaction can be accepted, because:

if (!CheckAssetLockUnlockTx(tx, pindex, pool.indexes, state)) {

CheckAssetLockUnlockTx validates only against indexes from previous block.

But it is not true, because it's just simple basic validation of transaction. Proper validation happens on next step, when validated both "transaction index" and "credit pool unlock limits":

CCreditPoolDiff::Unlock:
    if (sessionUnlocked + toUnlock > pool.currentLimit) {                                 
        return state.Invalid(TxValidationResult::TX_CONSENSUS, "failed-creditpool-unlock-too-much");
    }   

    if (pool.indexes.Contains(index) || newIndexes.count(index)) {                        
        return state.Invalid(TxValidationResult::TX_CONSENSUS, "failed-creditpool-unlock-duplicated-index");
    }   

So, index is tested against both list: list of indexes that have been ever used since Tip() and list of indexes that are freshly introduced in just this block.

Unfortunately, I can't add a functional test for it because:

• same transaction will have same hash -> refused to be added in mempool
• no quorum can sign transaction with same index but with different hash -> impossible to get 2nd tx with same index.
  And because at least one of this tx is invalid it can't be mined - not because same index, but by other reasons (wrong signature or same hash).

Any ideas how to test it otherwise?

[PastaPastaPasta]

utACK for squash merge (open to other thoughts by Udjin)

[UdjinM6]

utACK

[ogabrielides]

LGTM