BIP-0157: increase max getcfilters request to 1k blocks

In this commit, we effectively revert bitcoin#699 by allow clients to request
filter for up to 1k consecutive blocks. Testing in the field has shown
that applications are able to reduce perceived latency from syncing to
full functionality after an app has been offline for several days by
batching requests for filters. A value of 100 would mean each additional
day behind adds an additional round trip, resulting in 10s of
seconds of lag after just a few days of being offline. A value of ~1k
allows implementations to catch up with roughly a week's worth of
filters in a single round trip.

Author: Roasbeef

bip-0157.mediawiki

@@ -168,7 +168,7 @@ fields:
 
 # Nodes SHOULD NOT send <code>getcfilters</code> unless the peer has signaled support for this filter type. Nodes receiving <code>getcfilters</code> with an unsupported filter type SHOULD NOT respond.
 # StopHash MUST be known to belong to a block accepted by the receiving peer. This is the case if the peer had previously sent a <code>headers</code> or <code>inv</code> message with that block or any descendents. A node that receives <code>getcfilters</code> with an unknown StopHash SHOULD NOT respond.
-# The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 100.
+# The height of the block with hash StopHash MUST be greater than or equal to StartHeight, and the difference MUST be strictly less than 1000.
 # The receiving node MUST respond to valid requests by sending one <code>cfilter</code> message for each block in the requested range, sequentially in order by block height.
 
 ==== cfilter ====