Not all provided CRLs might match the CA, thus use only ones coming from
given CA.

See merge request !13

These scripts automate part of the work needed on the client side of
kedifa:
- retrieving the secret token, storing it along with server authentication
  (CA cert and CRL) paths
- serialising a key and certificate pair the way kedifa expects them, and
  pushing the result to kedifa

 * *: defined encoding on each file
 * app: use b'' or encode before returning with wsgiref
 * cli: switch to binary for files
 * test: decode/b'' or encode when needed

As the servers can take a bit of time before emitting the log entry, wait a
bit before asserting the status.

pylint understands this and does not report errors about accessing
undefined members.

http://pylint.pycqa.org/en/stable/faq.html#how-do-i-avoid-access-to-undefined-member-messages-in-my-mixin-classes

See merge request nexedi/kedifa!11

See merge request nexedi/kedifa!10

caucase.util.load_crl API changed in an incompatible way in caucase 0.9.9 .
This change fixes the API breakage and adds support for mor than one CRL
in kedifa.app.http .

By inserting other CA certificate as first one in the list, the problem is
reproduced in the test.

Depending on the environment, various exceptions can be risen, so be tolerant
regarding the exception type.

/reviewed-on nexedi/kedifa!5

It can fail too fast, without giving caucase any chance to start really.

It's better to reply 400 Bad Request on malformed requests and do not pollute
log with exceptions.

Also improve message in case of failure.

/reviewed-on !4

As updater is used in environment, which requires it to have certificates
available as fast as possible, add a prepare step and allow to launch it with
--prepare-only switch.

Thanks to this it is possible to run it with configuration file to provide
fallback or master certificates for all slaves without connecting to the
network, thus resulting in fast preparation.

/reviewed-on !3