fix: update miner mempool iterator query to consider both nonces and fee rates

[rafaelcr]

Problem

The current query used by Stacks miners to iterate over pending mempool transactions sorts them only by fee_rate in descending order. This approach creates the following problems:

1. Since it does not consider transaction nonces, non-mineable transactions with high fees but old (or very future) nonces go to the top of the list and get visited every time, thus wasting block construction time budget.
2. Transactions with null fee rates are sent to the bottom of the list even if their nonces should be evaluated next, forcing the algorithm to query them separately with some probability of inclusion.

Solution

This PR changes the transaction selection query to a new one that prioritizes those that can be confirmed as fast as possible (lowest valid nonces) with the highest fees as possible. This means that even if it doesn't select the transactions with the highest global fees first, it will select those that can be mined faster therefore optimizing block building time and allowing the miner to fit in more transactions in total within the allotted time.

The new query also mixes in transactions with null fee rates in results by simulating a fee rate for the purposes of ordering only.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[rafaelcr]

@obycode I added a simulated fee rate (for sorting only) when it's NULL. It successfully mixes in null txs with estimated txs in a randomized order. What do you think?

[obycode]

That's a great idea! I like it.

[obycode]

Could you also take into account the settings.consider_no_estimate_tx_prob here? I'm not sure how important it is to keep that config parameter.

[rafaelcr]

I believe we don't need it anymore, however, if necessary I could use it as a probability to skip a null transaction altogether. Thoughts?

[obycode]

I think probably this random mix in is good on its own and we can deprecate that option.