Issue title: Notes on Compact Block getdata fallback responses
 Issue body: This came up at a meeting a while back, but I realized it was never materially written down anywhere.

Compact Block high-bandwidth processing can fall back to getdatas when the client belives a short id collision may have occurred (among a few other cases). In such cases, we are required to wait until we have verified the full block before we can respond to the getdata request (hence the few awkward ActivateBestChain calls in net_processing). However, in case we find the block to be invalid (or decide its actually not our best-chain-candidate due to some race receiving another block in parallel) we will simply leave the getdata unresponded to. This will result in us eventually getting disconnected for stalling.

It is important to note that, were an attacker able to generate a block which, when relayed, would cause getdata fallbacks on an invalid block, such an attacker would be able to cause massive disconnections across the network, especially targeting mining nodes or other nodes which receive blocks particularly fastly. I do not believe such creation is currently possible, but definitely could be bad if we did something dumb like fixing the nonce in the future.

During the meeting we discussed using the existing NOTFOUND message for block requests as well, which seemed to have some level of support (or a BLOCK_NOTFOUND or whathaveyou) and using that to allow peers to simply reject providing a block without being disconnected as a staller.
 Comments: 
 Comment 0: It appears this might still be a potential issue in 24.0rc1 and master.

IIUC when node A detects a short id collision on a compact block it will request the full block from node B with a `getdata`:

https://github.com/bitcoin/bitcoin/blob/def75f0fb51b2d2d54cd4d772cf54d45b0fa5ae8/src/net_processing.cpp#L4195-L4201

 If node B has in the meantime determined that block to be invalid after validation (or re-orged it) then the following clause will execute causing node B to never respond to the `getdata` request for the block:

https://github.com/bitcoin/bitcoin/blob/def75f0fb51b2d2d54cd4d772cf54d45b0fa5ae8/src/net_processing.cpp#L2106-L2109

One thing that is not immediately clear to me is where node A marks B for disconnection in the case a `getdata` is not responded to; is this still how the P2P protocol works internally?

If the disconnection is still a prospect, it does seem that using the `NOTFOUND` message is the approach that makes the most sense, and avoids having to add a new message.
{'source': 'GithubIssues', 'repo_name_with_owner': 'bitcoin/bitcoin', 'issue_id': 328621862, 'repo_stars': 66723.0}