With this patch, requests issued while the client is in the
'CONNECTING' state get queued instead of raising a misleading
'SessionExpiredError'.

This fixes https://github.com/python-zk/kazoo/issues/374, and brings
Kazoo more in line with the Java and C clients.

See the 'kazoo.client.KazooClient.state' documentation as well as
these discussions for more details:

https://github.com/python-zk/kazoo/pull/570#issuecomment-554798550
https://github.com/python-zk/kazoo/pull/583#issuecomment-586422386

Satisfy new Hound style/lint checks
Upgrade to latest 3.5.6/3.4.14 Zookeeper releases.

Since krb5 1.3 due to switch to Xenial.

fix(tests): prefix with toxinidir variable with a / to ensure path to ensure-zookeeper-env.sh is correct

 * Install debian packages for KDC as part of Travis init.
 * Setup a loopback mini KDC for running tests.
 * Run SASL tests as part of Travis builds.
 * Improve harness cluster to support:
    * Reconfiguration when environment changes.
    * Different JAAS configurations (DIGEST/GSSAPI).
 * Moved SASL tests into own module, with specially configured harness.
 * Bumped default timeout to 15 sec to mitigate false negatives on
   Travis.

feat(core): Add create2 support

New retry logic takes a maximum percentage off the canonical backoff,
ensure gradual predictable retries timings while still having a
controlable amount of jitter (re-introducing the `max_jitter` parameter)
to avoids swarming client retries.

Fix regression introduced in 60366d2c
where retry/backoff logic produced only whole second (integer) retry
delays.

This produced inadequate retries on first retry and would generally not
work on fast network where sub miliseconds retries are desired.
Additionally, with high `max_delay` setting, as the range was always
spanning from 0 until the last delay, it would also produce extremely
random results with short delays following longer ones which is contrary
to the expected backoff logic.

When connection attempts fail repeatedly (e.g. all ZK servers are
unavailable), eventually the socketpair in the ConnectionHandler fills
up, and the Client gets stuck trying to write a single byte to the
socketpair.

Avoid this by ensuring we close the socketpair on a failed connection
attempt.

* Switching to xenial distrib to make python 3.7 available

* Testing against 3.5.5 instead of 3.5.4-beta and deploying new version for python 3.7 and zk 3.5.5

* Testing against zk 3.4.14 instead of 3.4.13

* Change pattern for slf4j-log4j lib

* Since ZOOKEEPER-3156 it is now required to be authed to access ACLs

* Drop support for ZK 3.3.x and Python 3.{4,5}

In order to be better in sync with the official documentation (https://zookeeper.apache.org/doc/r3.5.5/zookeeperProgrammers.html#ch_zkSessions) it is better to rename those variables to `close` instead of `lost`.

Avoid
```
  File "/home/tests/kazoo/recipe/lock.py", line 341, in contenders
    contenders.append(data.decode('utf-8'))
AttributeError: 'NoneType' object has no attribute 'decode'
```

Add parameters to setup SSL context options and ciphers when playing with secure connection.
It can be set via a handler:
```
class MySequentialThreadingHandler(SequentialThreadingHandler):
    def create_connection(self, *args, **kwargs):
        return create_tcp_connection(socket, options=MY_OPTIONS, ciphers=MY_CIPHERS,
                                     *args, **kwargs)
```

* feat(recipe): add support for curator SharedCount recipe

This feature allows Java clients using curator's SharedCount recipe
and python clients using kazoo's Counter recipe to read and
write from the same path without receiving type errors.

example use:

counter = zk.Counter("/curator", support_curator=True)
counter += 2
counter -= 1
counter.value == 1
counter.pre_value == 2
counter.post_value == 1

Closes #558