Improve blob size transaction selector

[fab-10]

PR description

The main goal of this PR is to make clearer the reason a blob tx is not selected during block creation, with the introduction of 2 specifics not selected results:

• BLOBS_FULL = The block already contains the max number of allowed blobs.
• TX_TOO_LARGE_FOR_REMAINING_DATA_GAS = The transaction has not been selected since there is not enough remaining data gas in the block to fit the blobs of the tx.

and to achieve that it was clearer to extract the blob tx selection login in its own class BlobSizeTransactionSelector, while doing that a small bug was fixed, since data gas used was added to gas used when computing if a block was full, while these 2 gas types are independent, see here for details.

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[fab-10]

adding blobGasUsed is incorrect here, since here we only want to check the gas used and not the data gas used

[Gabriel-Trintinalia]

Can we use the term blob gas instead of data gas? for the variables and transaction selection reasons?

[macfarla]

from reading the description this PR is doing 4 very excellent things, but would be easier to review as several smaller PRs

[fab-10]

from reading the description this PR is doing 4 very excellent things, but would be easier to review as several smaller PRs

Fair point, splitting in 3 PRs:

first one Stop transaction selection on TX_EVALUATION_TOO_LONG
second one Fix and restore disabled block creation unit tests

the fix to blob gas is related to this refactor so make sense to keep in this PR

[fab-10]

Can we use the term blob gas instead of data gas? for the variables and transaction selection reasons?

I also like more blob gas because is more common, and I will rename to it, but in many other places we have data gas like the DataGas type, so it is up to another PR to align the naming everywhere