Signalfx

The main change in 1.0.18 is that payloads of datapoints sent to SignalFx will
now be compressed by default (using GZip compression and `Content-Encoding:
gzip`). This can be disabled by specifying `compress=False` on the SignalFx
client, or on the ingest sub-client directly.

Added support for the new `immediate` flag when executing SignalFlow
computation. Setting this flag to `true` forces the system to shift the
timerange of the computation by the `maxDelay` amount (either detected, or
specified), to ensure that the computation returns and completes without
additional delay to wait for late data.

Also added support in the library to access event metadata on events received
from a SignalFlow computation.

Updated the default TCP timeout to 5 seconds to match our Java and Ruby
libraries.

Added support for compressed SignalFlow WebSocket messages, which improves the
streaming performance by reducing the bandwidth requirements of the client.

Added support for the detector preflighting API, allowing for the execution of a
detector program in a mode that simply summarizes the events that would
otherwise be generated, allowing for the quicker execution of that preflighting
over longer spans of historical data.

This release also includes a bugfix to how the total number of input timeseries
is calculated, as well as support for a new version of the binary data message
encoding (not yet used).

Fixes a bug in the SignalFlow streaming computation client library that would
lead to an incomplete first data batch returned from the computation stream when
the program being executed as multiple published streams.

All three sub-clients also now support Python context managers so they can be
used in `with` blocks:

python
with signalfx.SignalFx().signalflow('MY_TOKEN') as flow:
computation = flow.execute(program)
for msg in computation.stream():
...

Added support for the `/v2/detector/validate` endpoint via
`rest.validate_detector()`, and support for searching detectors by tags when
using `rest.get_detectors()`.

It is also now possible to pass `ignore_not_found=True` to REST delete
operations to ignore failures on attempting to remove a non-existent resource
for which the DELETE call would otherwise return a 404.