[#6301] Track bad block cause

[mbaxter]

PR description

Track bad block causes in BadBlockManager in preparation for exposing plugin events. This data is useful because a consumer may want to take a different action depending on the cause. For example, for #6301, we probably want to trace blocks with an actual validation error and ignore blocks that just descend from a bad block.

Summary of changes:

• Require a BadBlockCause when pushing blocks to BadBlockManager
• Simplify bad block checks by adding utility method BadBlockManager.isBadBlock
• Add some basic tests for BadBlockManager
• In event handler MergeCoordinator.onBadChain, only push descendants of the bad block to theBadBlockManager. The bad block itself will already have been pushed into the BadBlockManager when processed in MainnetBlockValidator and the MergeCoordinator does not have the context on why the bad block was marked as bad.
• Remove unused API MergeMiningCoordinator.addBadBlock
• Fix / add tests to MainnetBlockValidatorTest
  • Add tests for fastBlockValidation()
  • Set all mocks upfront to ensure every test executes from a baseline of success. Previously several tests were passing artificially. The mocks were not set up correctly so some tests were not hitting the cases that were intended.
• Create some factory methods on InvalidBlockException to handle cases where (previously required) block data is not available
• Disambiguate a few different types of errors in DownloadHeaderSequenceTask and add tests

Fixed Issue(s)

Part of #6301

[mbaxter]

@siladu - I have already pinged @garyschulte and @jflo for a review if you are busy

[jflo]

Overall big improvement in observability and readability! I think we need to think through the treatment of any RuntimeException as a bad block, that is a lot broader than known application exceptions like StorageException and MerkleTrieException. If that gets thrown unexpectedly and a protocol-compliant block is marked as bad, there will be a chain halt.

[mbaxter]

I think we need to think through the treatment of any RuntimeException as a bad block, that is a lot broader than known application exceptions like StorageException and MerkleTrieException. If that gets thrown unexpectedly and a protocol-compliant block is marked as bad, there will be a chain halt.

See inline response here.