Add validation description for LightClientBootstrap + Update

[kdeme]

This explicitly adds the validation mentioned in step1 for #296 and #305

[acolytec3]

This looks fine to me. A while back, I implemented an alternative solution in Ultralight for identifying a "probably" trusted bootstrap (basically just requesting recent LC updates and trying to gain a majority view on a trusted block root from comparing the responses provided of multiple peers) though that's not reliable except in a probabilistic way. Any opinions about including something like that as a fallback way of joining the network (e.g. in the case where a trusted block root can't be acquired directly?

[pipermerriam]

Any opinions about including something like that as a fallback way of joining the network

IMHO I think you should require a trusted block root to enter the network and using a probabilistic approach that can't be guaranteed is probably irresponsible client design at this stage of client development. If anything, it introduces an incentive to attack our network since it's very directly able to be attacked by spinning up a large number of malicious nodes.

[kdeme]

Any opinions about including something like that as a fallback way

I think this should be a client implementers choice, as I would probably advise against it for reasons that @pipermerriam points out.
If it does turn out to be too big of an issue that many bootstraps are not available, we should move to the version where we provide all bootstrap (back-fill) with proofs against the roots of the historical_summaries.

[pipermerriam]

To be clear, I'm advising against the probabilistic approach mainly because I think it will be a time sink at this stage of protocol development, and the trusted root approach should be simple to implement. I fully agree that clients can and should choose to to implement whatever approach they prefer here.