LocalStateQuery: let the client acquire the immutable tip

[nfrisby]

Description

We will use this to make it easier for the CLI to only output answers that are not subject to rollback.

This change to LocalStateQuery is gated by NodeToClient_Version16, since that is still mutable (it enables Conway et al).

It is a breaking change for any code that involves MsgAcquire or MsgReAcquire, since the type of the argument has changed to a new (more perspicuous and expressive) ADT.

Checklist

• Branch
  • Updated changelog files.
  • Commit sequence broadly makes sense
  • Commits have useful messages
  • The documentation has been properly updated
  • New tests are added if needed and existing tests are updated
  • If serialization changes, user-facing consequences (e.g. replay from genesis) are confirmed to be intentional.
• Pull Request
  • Self-reviewed the diff
  • Useful pull request description at least containing the following information:
    • What does this PR change?
    • Why these changes were needed?
    • How does this affect downstream repositories and/or end-users?
    • Which ticket does this PR close (if any)? If it does, is it linked?
  • Reviewer requested

[nfrisby]

The CI complains that "./ouroboros-network-api was modified but its CHANGELOG was not updated". But the change is just a comment that does not deserve mention in the CHANELOG.

Do you have advice for how to proceed?

[coot]

Very nice, thank you @nfrisby.

[nfrisby]

For "If serialization changes, user-facing consequences (e.g. replay from genesis) are confirmed to be intentional.", here's some quotes from a Slack discussion with @ch1bo :

[T]he serialization is backwards-compatible (I used a fresh tag for the new option, whereas the new data structure still has constructors that match the old Nothing/Just constructors and therefore use the same CBOR tag)

My general assumption is that no one downstream of Consensus is caseing over these messages (other than maybe formatting log messages, etc). So your experience should mainly be: there's a new constructor you could choose to call, but you shouldn't if the handshake version negotiated with the server (ie the local node) is too low. (Like Marcin said, if you construct it even if the negotiated version is too low, you'll get an encoder failure on the client side (eg the wallet). If a buggy custom encoder ignores the version, the node will simply disconnect due to the ill-formed message.)

Summary:

Server (ie node)	Client (eg wallet)	Notes
new	new	Both know about ImmutableTip ✔️
old	old	Neither knows about ImmutableTip ✔️
new	old	Server could handle ImmutableTip, but client won't send it ✔️
old	new	Our encoders error on the client side if the client logic ignores the negotiated version ✔️; if a buggy custom encoder sent it through, the node would simply disconnect due to a serialization failure ✔️

Also: the existing messages' serialization wasn't changed, but their data constructor names were improved.

[nfrisby]

I'm assuming the panoply of darwin failures is Hydra's fault, not mine.

[coot]

I'm assuming the panoply of darwin failures is Hydra's fault, not mine.

It seems so, I restarted them.

[nfrisby]

I rebased and squashed my commits (and removed the merge commit that Marcin pushed).