light-client: add missing RPC endpoint and extend handler/supervisor

[liamsi]

#219 (comment)
and contains a preliminary fix for #450 (thanks @OStevan)
closes #450
closes #219

• Referenced an issue explaining the need for the change
• Updated all relevant documentation in docs
• Updated all code comments where relevant
• Wrote tests
• Updated CHANGES.md

[liamsi]

TODOs:

• add tests
• update light-node Readme
• changelog?

[brapse]

🎉 🚢 💡 💁 💼

[xla]

Dope! Very straighforward extension.

The issue I see is that we make the entire LatestStatus optional. Which for my understanding of an operational endpoint is confusing and actually reducing the signal, as for the caller it's unclear what the reason might be, as the system only returns one when there is a primary with a trusted block. Instead we should always return a proper response and make fields in there optional. This part should be addressed in this PR IMHO.

Beyond that the real value of this new endpoint comes from the peer list, the other info can be obtained from the state endpoint. We would benefit by reworking the status one into giving operational insight, like what's the state known for a given peer, latest block, status of latest block and if they are our current primary. In a very far future this could expose the different lists in PeerList. We can look into that in follow-ups.

[liamsi]

The issue I see is that we make the entire LatestStatus optional.

I think the reason is exactly the same as why the endpoint you created is optional too but yeah, you are right in this context it is important to return any information if it is available. Do you think that all these fields should basically be optional then?

[xla]

👂 ⛰ 🆘 🏃

[romac]

Looks great! 👍

Just a quick note on the new LightStore::latest method: self.db(status).iter(&self.db).max_by does a full linear scan of the database, so this might perform very badly as the light store grows. Not a blocker for this PR, but just something to keep in mind for when we revamp the LightStore. Will add a reference to this comment to #428.