network/stream: fix flaky tests and first delivered batch of chunks for an unwanted stream

[acud]

This PR addresses three problems:

1. TestStarNetworkSyncWithBogusNodes was flaking on travis due to a too short sync delay timer. This, at least to my interpretation, means Swarm is getting slower over time. We should keep this in mind
2. TestNodesCorrectBinsDynamic was flaking because syncing was hardcoded to Autostart all the time. This resulted in incorrect bin indexes exchanged because some syncing has already occurred and has introduced non-determinism on the state of binIDs so as the cursors of the nodes. This is solved by a configurable parameter on SyncSimServiceOptions that toggles whether streams should be autostarted
3. A bug in stream package resulted in a first delivered batch of chunks before an unwanted stream is actually dropped.

The scenario is the following: a node initially establishes streams on certain bins that become obsolete once kademlia depth changes (for example, depth is initially 0 and a stream on SYNC|0 is requested from a node with PO 2. Subsequently, kademlia depth changes to be depth 3 and the subscription on SYNC|0 is no longer relevant). Before this fix, the ChunkDelivery messages that would be received would actually put the chunks into the localstore without checking that provider.WantStream()==true.

This resulted in a first requested range of a live stream always to be persisted, regardless whether that stream is wanted or not at the time of reception. The data race happened when the depth changed between HandleOfferedHashes and the call to requestSubsequentRange at the end of clientHandleOfferedHashes method.

This has now been amended to have the appropriate checks in clientHandleOfferedHashes and clientHandleChunkDelivery handlers.

A change in kademlia depth is still possible between the send of WantedHashes message and the reception of the first ChunkDelivery message. Another change in depth can occur in between ChunkDelivery messages, in the case that the batch is split up to several messages. The two latter cases, however, are mitigated with the check that was added within clientHandleChunkDelivery handler, which will not process the chunks by returning, eventually causing the batch to time-out within clientSealBatch and the subsequent range to never be called

[janos]

This my result in different behaviour on Autostart default value. If o is nil, Autostart is true, but if o is not nil, but some value which does not specify Autostart, Autostart will be false like & SyncSimServiceOptions{SyncOnlyWithinDepth: true}, which is inconsistent. I think that the boolean should be named in respect to default value being consistent in both cases, like NoAutosync.

This is even visible in this PR. Options are constructed just to set Autostart to false explicitly, even if it is a default value for the field.