Update collator-protocol for asynchronous backing

[rphmeier]

If the runtime API version indicates that asynchronous backing is supported, we should handle more advertisements and second more candidates.

[rphmeier]

AdvertiseCollation in network v2 should have (RelayParentHash, CandidateHash, ParentHeadDataHash) where the relay-parent is the relay-parent of the candidate. The new CollationFetchingRequest needs to include the candidate hash.

We'd use GetMinimumRelayParent on both sides to track which collations are acceptable in a view, so each active-leaf comes with an implied ancestry of a few relay-parents allowed for announcements.

For validators:

We'll need to make use of GetHypotheticalDepths from #4913 , as well as some new message type which tells us when new blocks are seconded or backed for a para. We should allow collators to make a few (up to MAX_DEPTH?) announcements per relay-parent and we'll keep but not act on announcements that we don't recognize with GetHypotheticalDepths. When we learn of new candidates getting seconded in the relevant fragment trees, we'd try GetHypotheticalDepths again. We might optimize this by having the mechanism for teaching us about new seconded candidates tell us the head-data hash so we can compare it to the announcements we have.

We should only fetch & second collations that are either built on top of the root of some fragment tree or have a parent which is backed. We could relax this somewhat to fetch & second collations that are built on top of a Seconded candidate which we've validated locally, but that'd be more complex and the 'backed' rule should work OK although it's not as efficient.

We need the collation-fetching response to be more sanity-checked to make sure it actually matches the stuff in the announcement.

We also need to obey the rule that we only second 1 block per depth per active leaf (as opposed to implied relay-parent!)

For collators:

Less needs to change here: we'd use the same implied ancestry logic to figure out what we're allowed to advertise to validators that we're connected to, and we'd need to keep around more stuff in memory to answer requests.

[eskimor]

We should only fetch & second collations that are either built on top of the root of some fragment tree or have a parent which is backed. We could relax this somewhat to fetch & second collations that are built on top of a Seconded candidate which we've validated locally, but that'd be more complex and the 'backed' rule should work OK although it's not as efficient.

Because it just tripped me again: 'backed' in this context means we have seen enough votes to consider it backed - it is not yet backed on chain, otherwise the above would make little sense.

[rphmeier]

Yeah. I opened a follow-up for the optimiation of the fetching rule as well

[rphmeier]

related: #5923