Update Supervisor and Detector to add at most one lightblock per call

[josef-widder]

In
https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_001_reviewed.md

we are currently cross checking all lightblocks from the verification trace provided by the primary. The reason is that we currently add the complete trace to the lightstore, and we only want to add trustworthy lightblocks. This seems inefficient in practice, and the intermediate lightblocks in the lightstore may not be needed.

We will

• update the supervisor currently living in Light client supervisor #159 and create a new PR: If no evidence is returned by the attack detector, the last lightblock of the verification trace is added to the lightstore
• update the detector to
  • first crosscheck the last lightblock with all secondaries
  • if they all match we return empty evidence
  • if one is not matching we go into deeper evidence creation with all of them

[josef-widder]

At second thought, we have to understand the tradeoff with maintaining verification traces. Perhaps it makes sense to parametrize the light client for light node use and for IBC/relayer use. @milosevic and I will discuss this next week.

[cezarad]

Also if the evidence is custom made, the trust between two might not be the same as the global trust across all witnesses and the primary, at least at first until all checks are done. Actually the global trust is built from the pairs trust, so maybe we should be careful with cycles.

[josef-widder]

After the discussion with @milosevic and @cezarad today, I think the should do the following:

• maintain states on the lightblocks (verified, trusted)
  • we check targetheight against the secondaries, and if they match we set the block to trusted
  • we keep verified headers in the lightstore (we will use them for IBC attack detection and submission)
• maintain verification information (which block is based on which)
• only use trusted blocks for normal operation (checking transactions in blocks, installing blocks in IBC handlers)
• use verified and trusted for submitting attack evidence to IBC (here we actually do not care whether the conflicting trace we install actually is trusted or from the blockchain. We are sure there has been a light client attack, and to ensure safety we need to stop the IBC handler)

Rationale:

• for running the lightnode and for installing headers on IBC handlers we only should use trusted headers (we could drop the verified headers and only store the trusted ones)
• for IBC fork detection it is OK to also use verified headers (verifed is enough, we don't care about trusted)

=> there are two different use cases. To capture both in one lightclient, we maintain the state information.

(We need to capture in the supervisor the case where in a later iteration, a block that has been verified should be "set to trusted")

[josef-widder]

Done here #215 and #186