toHTTPS was only taking care of scheme, which is not enough. So use
self._https_url directly.

Avoids hardcoding newline char.

Otherwise, verification against IP-only CA certificate will fail, as
common name is sometimes used to contain a domain name (which is
deprecated in favour of alternative names, but still checked).

What was not picked up by 2to3.

Using only 2to3 conversions which are python2-compatible.

Self-describe site structure in application/hal+json format.
Add Cross-Origin Resource Sharing support: pre-flight request support,
same-origin-only origin access control minimal html page. Access control
decision is stored client-side in a signed & time-limited cookie
supporting multiple concurrent origins. Origins may be pre-allowed (ex:
when caucase GUI is served from a trusted server).

This makes it safer to trust this CA certificate in general-purpose https
clients, like web browsers, as it prevents such trusted CA certificate
from issuing rogue certificates.
Bump pyOpenSSL to latest version (and, as a consequence of pyOpenSSL
18.0.0 itself requiring cryptography 2.1.1, bump it as well) as it seems to
fix a bug related to validating NameConstraints - and anyway fixes
worrying use-after-free errors.

This is a step in the direction of being browser-friendly: if caucased
https certificate is issued by CAS CA, then for a browser to trust that
certificate it would have to trust all certificates emitted by CAS CA
certificate. This would be very dangerous, as CAS CA does not constrain
the certificates it may sign, so it exposes users of that caucased to
rogue certificates.
Alone, this step is insufficient, as the new internal "http_cas" does not
constrain certificates yet. This will happen in a separate commit, to
ease review and regression testing.
As a consequence of this step, by default client will not check server
certificate in https. This is consistent with how trust is bootstrapped
with plain http: maybe client is accessing an unexpected/malicious
caucased, but in such case issued certificates will be worthless to a
party which could access the correct caucased. Also, the client
certificate presented to caucased does not allow that caucased to fake
being that user, so there is no privilege escalation possible for
server.

/reviewed-on nexedi/caucase!3

Maybe name resolution is flapping, or server is unreachable or
misbehaving... This must not cause caucase-update to exit.

So they can be customised in subclasses.

So that they do not hardcode the class to instanciate.
This prepares further class tweaking.
Also, update users.

Work around a python bug (both present in 2.7.15 and 3.6.6) which prevents
changing the ssl context on a listening socket.
Reported: https://bugs.python.org/issue34747

The code could actually not loop. Still check that deadline is not reached
when entering, as code often uses "now" as initial deadline.
Also, clarify dosctring.

Do not wait forever so test does not block.
Always clear event after it occurred.
Also, ensure itsUntilEvent behaviour is to raise so server actually stops
in _stopServer.

So the instance is readily reusable and less likely to be misused.

Spawned thread is not returned.

Except it is not present on caucase root object.
This reverts commit b26eeb38.

It is not in python3.

To ease debugging.

The intent was getting a nice error message if file was not readable, but
it causes a resource warning in python3 (file object being garbage-
collected while open - wasn't that the beauty of automatic garbage
collection to begin with ? It makes sense for writeable files as not
closing may cause race conditions, but for read-only it's just annoying).