Modify `testmempoolaccept` to handle client's `max_raw_tx_fee` check failure #21074

See #21062 (review)

testmempoolaccept handles this case since it was written. See also the test

https://github.com/bitcoin/bitcoin/blob/f72d80b07af8ecbb2f9df1e87344eb465186f19d/test/functional/rpc_rawtransaction.py#L478-L480

Note the reason has been changed from absurdly-high-fee to max-fee-exceeded

@MarcoFalke As of ea96e17, testmempoolaccept's "allowed" field is documented "If the mempool allows this tx to be inserted". Your transaction might be mempool valid but doesn't pass the client belt-and-suspender, a different type of check so we should return allowed=true in that case.

This is ambiguous and IMHO we should have a different result field to dissociate cleanly. And also nicely return fees to offending caller and such allow correction ?

As of ea96e17, testmempoolaccept's "allowed" field is documented "If the mempool allows this tx to be inserted".

That is the case since the call was added in commit b55555da3e25a47f1e7fced7f09d4f0bf8198624.

we should return allowed=true in that case.

That'd be a breaking change, so I'd rather not do that.

This is ambiguous

This is documented, so shouldn't be ambiguous:

2. maxfeerate      (numeric or string, optional, default=0.10) Reject transactions whose fee rate is higher than the specified value, expressed in BTC/kB

Maybe you are asking for the reject reason to be better documented in that case? Simply checking the reject reason should be sufficient in this case to dissociate cleanly.

Conceptually, I agree that the information given isn't as precise as it could be. If we could start from scratch, I would do it differently. The idea for #19339 not changing allowed from False to True was, as @MarcoFalke said, because that'd actually be a breaking change, so it just changes the reject reason instead. I don't think users would be surprised by the behavior given current documentation.

Moving forward, if I were to propose something, I'd maybe have allowed represent "everything ok," and then for "allowed=False" add a problem-type field for CONSENSUS, MEMPOOL_POLICY, USER_CONFIG, or UNFINISHED_VALIDATION. Just throwing the idea out there.