Update lookahead on Polkadot and Kusama

[tdimitrov]

With the collation fairness the validators won't fetch advertisements for which there is no free spot in the claim queue. At the moment on Polkadot and Kusama lookahead is set to 2 while max_candidate_depth is set to 3.

We need to bump lookahead to 3 on Polkadot so that we still allow the collators to advertise up to three candidates per relay parent. On Kusama I guess we should bump the lookahead to 6 for the same reason. On Kusama we should do the same.

Additional benefit from this change is making the upcoming async backing params deprecation smoother. With this change max_candidate_depth will effectively be the number of claims in the claim queue for the given parachain. Keeping max_candidate_depth aligned with lookahead (the claim queue size) definitely helps.

Initially brought up by @alindima in https://github.com/paritytech/polkadot-sdk/pull/4880/files#r1842254623

Open questions:

• Are there any unwanted side effects from bumping lookahead to 6 on Kusama? -> Not bumping to 6 on Kusama.
• For consistency should we also set allowed_ancestry_len to 3 on Polkadot and 6 on Kusama?

[alindima]

I doesn't need to be 6 on kusama. It is 6 there because it includes the candidates pending availability. 3 is enough for the lookahead. The lookahead is actually more closely related to the allowed_ancestry_len.

For consistency should we also set allowed_ancestry_len to 3 on Polkadot and 6 on Kusama?

I don't think we should change this

[sandreim]

We bumped max_candidate_depth to 6 on Kusama to enable elastic scaling with up to 3 cores (MVP). We shouldn't need any other changes.

[sandreim]

Keeping max_candidate_depth aligned with lookahead (the claim queue size) definitely helps.

When we compute the async backing params max_ancestry_len should equal lookahead not max_candidate_depth.

[tdimitrov]

Keeping max_candidate_depth aligned with lookahead (the claim queue size) definitely helps.

When we compute the async backing params max_ancestry_len should equal lookahead not max_candidate_depth.

Yes with elastic scaling makes sense not to touch it. I thought we want max_candidate_depth=6 with just one core which won't work with claim queue of size 3.