Gossip queries: sync complete is back (#826)

We previously insisted that `reply_channel_range` messages were not
overlapping: blocks content could not be split across multiple messages.

This made it possible to implicitly figure out when sync was complete, so we
re-purposed the previous `complete` field to a `full_information` field.

We now revert that change to allow blocks to be split across multiple
messages. An explicit flag is thus needed to signal that sync is complete.

Fixes #804

07-routing-gossip.md

@@ -723,7 +723,7 @@ Though it is possible, it would not be very useful to ask for checksums without
     * [`chain_hash`:`chain_hash`]
     * [`u32`:`first_blocknum`]
     * [`u32`:`number_of_blocks`]
-    * [`byte`:`full_information`]
+    * [`byte`:`sync_complete`]
     * [`u16`:`len`]
     * [`len*byte`:`encoded_short_ids`]
     * [`reply_channel_range_tlvs`:`tlvs`]
@@ -762,7 +762,7 @@ Where:
 
 The checksum of a `channel_update` is the CRC32C checksum as specified in [RFC3720](https://tools.ietf.org/html/rfc3720#appendix-B.4) of this `channel_update` without its `signature` and `timestamp` fields.
 
-This allows to query for channels within specific blocks. 
+This allows querying for channels within specific blocks.
 
 #### Requirements
 
@@ -781,23 +781,21 @@ The receiver of `query_channel_range`:
     - MUST set with `chain_hash` equal to that of `query_channel_range`,
     - MUST limit `number_of_blocks` to the maximum number of blocks whose
       results could fit in `encoded_short_ids`
-    - if does not maintain up-to-date channel information for `chain_hash`:
-      - MUST set `full_information` to 0.
-    - otherwise:
-      - SHOULD set `full_information` to 1.
+    - MAY split block contents across multiple `reply_channel_range`.
     - the first `reply_channel_range` message:
 	  - MUST set `first_blocknum` less than or equal to the `first_blocknum` in `query_channel_range`
 	  - MUST set `first_blocknum` plus `number_of_blocks` greater than `first_blocknum` in `query_channel_range`.
 	- successive `reply_channel_range` message:
-	  - MUST set `first_blocknum` to the previous `first_blocknum` plus `number_of_blocks`.
+	  - MUST have `first_blocknum` equal or greater than the previous `first_blocknum`.
+    - MUST set `sync_complete` to `false` if this is not the final `reply_channel_range`.
 	- the final `reply_channel_range` message:
 	  - MUST have `first_blocknum` plus `number_of_blocks` equal or greater than the `query_channel_range` `first_blocknum` plus `number_of_blocks`.
+    - MUST set `sync_complete` to `true`.
 
 If the incoming message includes `query_option`, the receiver MAY append additional information to its reply:
 - if bit 0 in `query_option_flags` is set, the receiver MAY append a `timestamps_tlv` that contains `channel_update` timestamps for all `short_chanel_id`s in `encoded_short_ids`
 - if bit 1 in `query_option_flags` is set, the receiver MAY append a `checksums_tlv` that contains `channel_update` checksums for all `short_chanel_id`s in `encoded_short_ids`
 
-
 #### Rationale
 
 A single response might be too large for a single packet, so multiple replies