Document the behaviour of chain-sync server

[coot]

Specifically document that sending MsgFindIntersect with empty list of points
would not result in a MsgIntersectNotFound replay, and the server
read-pointer is not touched.

[HeinrichApfelmus]

I have additional questions regarding the documentation of the ChainSync protocol (from the point of view of the wallet client), specifically the section labeled "Consumer starts with an arbitrary fork":

2. It has been indicated in conversations that after the sequence

   MsgFindIntersect [pt]; MsgIntersectFound (pt,tip); MsgRequestNext;
   

   the next message from the node to the client will be

   MsgRollBackward (pt,tip')
   

   if pt was different from the read-pointer before the first message sequence. However, this behavior is currently not apparent from reading the specification.
3. The spec currently says that upon receiving MsgFindIntersect (pt1:pt2:…) and finding that an intersection exists, the node will reply with "the best (i.e. the newest) of the points that it knows". For example, if pt1 is older (lower slot number) than pt2, then the node would reply with MsgIntersectFound (pt2,tip). However, if I read the code correctly, then the node replies with the first point it can find an intersection for, as opposed to the best point. In this example, this would often be pt1 instead of pt2. I suppose that it's just a matter of applying sort to the list of points, but if the client should do that, then documentation helps figure that out.

[coot]

Looking at the implementation it seems that the server will replay with MsgIntersectNotFound to MsgFindIntersect [], but it's true that the read-pointer is not touched (ref).