design: collators produce descriptors instead of receipts

[coriolinus]

I dug into this a bit more. I'm not sure we actually want collators to distribute descriptors instead of receipts. The reason being that it complicates candidate backing. Since we issue statements based on the candidate receipt hash, it's fast to check if we've already issued a statement on a candidate receipt we are being asked by another subsystem to second. If we only got a candidate descriptor, we'd always have to do candidate validation before knowing the hash of the candidate.

But that concern isn't too strong, since there is no guarantee that the candidate receipt commitments hash we get from a collator actually matches the outputs of validation.

A separate refactoring could replace pretty much everything in the collation pipeline with CandidateDescriptors, but note that it also requires changes in the Collation Distribution subsystem and the Candidate Validation subsystem by having CandidateBackingMessage::Second accept a CandidateDescriptor.

That all seems beyond the scope of this PR.

Originally posted by @rphmeier in #1557

[coriolinus]

In particular, the commitments_hash is likely to be wrong, because where it's constructed, we don't have enough fields to completely fill out the struct:

polkadot/node/collation-generation/src/lib.rs

Lines 236 to 240 in e5d25aa

	commitments_hash: (CandidateCommitments {
	upward_messages: collation.upward_messages,
	head_data: collation.head_data,
	..Default::default()
	}).hash(),

Whenever there are any fields with non-default values other than upward_messages or head_data, the hash is guaranteed to be wrong.

[edit] this comment is outdated; we added enough fields to completely fill out the struct.