More consistent with address extraction.

Python was unexpectedly binding utils.until to this class, causing "self"
argument to be automatically generated, which is not expected by this
function.
Tests do not exercise this code path because they are overriding this
property, precisely to check that it gets called...
Also, add docstring.

Not sure what this is doing here. There are not any failure masked by this.

stdout is supposed to accept bytes, not unicode objects.
And byte-ify all printed values to satisfy python3.

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.