validate bundles as they come in

[acha-bill]

Description

This adds a new QuickBundleValidation stage between Received and Broadcast stages. If the tx submitted to this stage is solid & is a tail, it propagates it via TransactionValidator#addSolidTransaction

Fixes #1810

Type of change

• Enhancement (a non-breaking change which adds functionality)

How Has This Been Tested?

• Existing unit tests pass
• Added difference scenarios that test edge cases for transaction solidity, tail and bundle validity.

Checklist:

• [x] My code follows the style guidelines for this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes

[acha-bill]

Currently, I'm counting only on quickSetSolid. Should we call TransactionValidator#checkSolidity before proceeding?

[GalRogozinski]

Hmm I think no... What I meant is that you will also take into account the propagtion thread in TransactionValidator (it will soon be moved to TransactionSolidifier in Dyrell's PR)

The problem with calling checkSolidity is that it opens up an attack vector by requesting txs that do not exist...

Even though that if you read the #protocol channel on discord you will see I am thinking of patching 1.9.0 with this

[DyrellC]

As it is right now it does add tails to the propagation queue as per

if (tvm.isSolid() && tvm.getCurrentIndex() == 0) {
    List<TransactionViewModel> bundleTransactions = bundleValidator.validate(tangle, true,
                        snapshotProvider.getInitialSnapshot(), tvm.getHash());
    if (!bundleTransactions.isEmpty()) {
        transactionValidator.addSolidTransaction(tvm.getHash());
    }
}

but it does not account for a transaction that solidifies at a later point. If we want to make sure we're catching every bundle as it's going through then it may make more sense to wait for 1805 and 1821 to get mergedd so that we have a queue for solidification. With that in place we can then have any transaction that makes it through checkSolidity it then performs a bundle validity check from the transaction solidifier while updating the state of the transactions and placing them into the propagation queue. If that's the approach we think makes the most sense, then replacing the transactionValidator.addSolidTransaction(tvm.getHash()) will need to change to transactionSolidifier.addToSolidificationQueue(tvm.getHash()), and if that transaction gets solidified quickly (which most should) it will then be added to the propagation thread anyways. This would mean that we will need to update the solidifier logic so that when it gets to the update phase, we should be running a bundle validity check on the original transaction before placing the transaction into the propagation thread.