Make sure all operations can be run concurrently multiple times about datastream

[kostko]

We have now implemented the following:

• Multiple downsample operations can be run concurrently and will use per-stream locking. (7a11b4c) Other downsamplers will not wait for the lock to be released, but will simply skip to the next stream. This introduced two new fields in stream metadata, _lock_mt that holds the timestamp when the lock will expire and downsample_count that holds a monotonically incrementing counter of performed downsample operations. During downsampling, if the lock is near expiry, we lengthen the lock.
• Interleaving of append and downsample operations is handled properly. (99d6fd3, 7124324) Before inserting the datapoint we update stream metadata to reflect the timestamp of the last inserted datapoint. In order to properly handle cases where multiple appends to the same stream interleave with downsample operations, we use a safety margin of 10 seconds. We maintain a per-stream list of datapoint timestamps inserted (or in the middle of being inserted) in the last 10 seconds which is checked before performing downsampling to select a minimum timestamp of them all. This timestamp is then used as a reference point for downsampling the stream. This guarantees that if append takes less than 10 seconds to complete (between updating stream metadata and actual datapoint insertion) downsampling will be consistent and will not skip datapoints that are pending insertion.

Handling concurrent backprocessing and derived streams is still pending.

[mitar]

Just to add to the comment above. So currently it means that you can downsample only until 10s before the last datapoint. (10s is used for above mentioned safety margin.)