Parent search for Aura should draw upon real asynchronous backing parameters

[rphmeier]

We should read the storage of the relay chain at the relay parent, but if it's not present fall back to a default hardcoded value of 0. Adding a utility function for reading the asynchronous backing parameters from the host configuration would be helpful for writing collators in the future.

cumulus/client/consensus/aura/src/collators/lookahead.rs

Lines 338 to 350 in 89af9a6

	async fn max_ancestry_lookback(
	_relay_parent: PHash,
	_relay_client: &impl RelayChainInterface,
	) -> usize {
	// TODO [https://github.com/paritytech/polkadot/pull/5022]
	// We need to read the relay-chain state to know what the maximum
	// age truly is, but that depends on those pallets existing.
	//
	// For now, just provide the conservative value of '2'.
	// Overestimating can cause problems, as we'd be building on forks of the
	// chain that can never get included. Underestimating is less of an issue.
	2
	}

[slumber]

I see 2 approaches we could follow there.

1. Introduce async_backing_params method to RelayChainInterface and attempt to call into runtime API, defaulting to { 0, 0 } in case it's not available. Unfortunately, the error in this case is

ApiError(Application(Execution(Other("Exported method ParachainHost_staging_async_backing_params is not found"))))

Doing String::contains is ugly and overall is a bad practice.

2. Use existing RelayChainInterface::get_storage_by_key, to read AbridgedHostConfiguration. Async backing parameters were placed directly under these fields (here), thus it should be safe, parameters were added in V6 migration on all chains. This diverges a little from what relay node does, but looks like a cleaner solution to me.

[rphmeier]

Yes, I recommend approach (2). It will be more future-proof.