grandpa: remove light-client specific block import pipeline

[andresilva]

Fixes #6893.

tldr: This PR removes a bunch of code related to handling of finality for the light client, essentially it removes the special casing and makes the light client use the same code the full client does.

The PR has 2 commits that can be reviewed separately.

Remove LightGrandpaBlockImport

The light client used a specialized block import pipeline that would not take in regular GRANDPA justifications but instead build "finality proof" requests which are an extension over justifications that allow proving finality of a block B with a justification for one of its descendents B'. Additionally the finality proof also comes with a storage proof for the authorities key.

In practice this isn't any lighter than just importing regular justifications using the full block import pipeline. I also think the storage proof is unnecessary, the light client will read the authorities from a header digest. If we can trust the storage root we can also trust the header hash.

I have not removed the code for actually generating finality proofs since this will be used in #7339. Some more cleaning up can be done in that PR.

Remove FinalityProof network protocol

The only user of the FinalityProof network protocol was GRANDPA's light import and since we're removing it I think it makes sense to avoid the burden of maintaining an unused network protocol (for example in #7478). In the future we will have some new network protocol for "warp" syncing the light client but the interface will almost certainly not match and breaking changes to the finality proof protocol would be required regardless.

polkadot companion: paritytech/polkadot#1954

[rphmeier]

In practice this isn't any lighter than just importing regular justifications using the full block import pipeline. I also think the storage proof is unnecessary, the light client will read the authorities from a header digest. If we can trust the storage root we can also trust the header hash.

The only thing we have to be careful of is which authority sets we allow to prove finality. We shouldn't be trusting anything from any given authority set until we've seen finality of the change to that set.

[tomaka]

Looks good to me from the networking perspective!
I've always wanted to remove this finality proofs protocol.

cc @mxinden you don't need to do finality proofs anymore in #6968

[andresilva]

The only thing we have to be careful of is which authority sets we allow to prove finality. We shouldn't be trusting anything from any given authority set until we've seen finality of the change to that set.

Just to be sure I understood what you meant here: with this PR the light client is essentially doing the same thing as the full node (minus executing blocks). It will validate all authority set hand offs in-order, so the change from SetId 1 -> SetId 2 will only be enacted after we import a justification signed by the validators from SetId 1.

[rphmeier]

It will validate all authority set hand offs in-order, so the change from SetId 1 -> SetId 2 will only be enacted after we import a justification signed by the validators from SetId 1.

Yep, that's alright.

[octol]

Nice to see so much red!
(More familiar with the grandpa changes than the networking ones...)

[tomaka]

Any reason to not merge this? 🙏

[andresilva]

bot merge

[ghost]

Trying merge.