Harden fetching of light blocks inside enclave

Context

Both RONLs and ROFL run consensus verifier inside the enclave with the embedded trust root. In case the light blocks are not available on the host local storage, they are fetched from the remote peers.

In https://github.com/oasisprotocol/oasis-core/pull/6526 the number of light providers was increased from 2 to 10. With i. max 3 retries before the process aborts and ii. single primary provider peer refresh if all providers fail (tryProviders), light blocks are now fetched from at least 12 peers compared to old 4 peers, before the runtime process aborts and later restarts.

Problem

Problem 1: We have cca 40 peers and only few of them might have ligth blocks, so ideally we try them all before aborting.
Problem 2: Peer fedback is not propagated out of enclave in case of invalid light blocks.

Possible solutions

1. Replace more than primary provider inside tryProviders if none of the providers responds.
   • Check that this does not somehow affect light client logic that expects static peers.
2. Extend RHP with request IDs and give enclave option to submit feedback.
   • Likely with smart client-server interaction and a bit of caching we might get rid of IDs as suggested by @peternose.
3. Use host as proxy and do peer validation/feedback on the host side, e.g. https://github.com/oasisprotocol/oasis-core/issues/6430. Obviously enclave still does its own validation.

Start by reviewing the light-provider changes in PR #6526 and the current tryProviders behavior. Compare the three proposed approaches, including the related design in issue #6430, and determine how light-client assumptions constrain provider replacement and peer feedback. Done means selecting and implementing a concrete approach that lets the enclave handle unavailable or invalid light blocks without premature process aborts.