Emit Certificate Revocation Lists signed by all valid CAs.
Apparently openssl (or at least how it is used in stunnel4) fails to
validate a certificate when CRL validation is enabled and the key which
signed the CRL differs from the key which signed the certificate.
Also, add Authority Key Identifier CRL extension, required to be standard-
compliant.
Also, fix revocation entry expiration: the RFC requires them to be kept
at least one renewal cycle after the certificate's expiration.
As a consequence of this whole change:
- the protocol for retrieving the curren CRL changes to return the
  concatenated list of CRLs, which breaks the CRL distribution (...but
  the distributed CRLs were invalid anyway)
- stop storing the CRL PEM in caucased's database so that it gets
  re-generated with fresh code. As caucased is not expected to be
  restarted very often, the extra CRL generation on every start should
  not make a difference.

Also, this provides a handy location to log all queries when debugging.
Also, some minor cleanups.

Because this is not the job of an import/export tool.

Rerun with updated nxd-relicense. This actually changes license text in
every file.

Before:

	W: caucase/__init__.py: cannot find license start
	W: caucase/_version.py: no copyright
	W: caucase/ca.py: cannot find license start
	W: caucase/cli.py: cannot find license start
	W: caucase/client.py: cannot find license start
	W: caucase/exceptions.py: cannot find license start
	W: caucase/http.py: cannot find license start
	W: caucase/http_wsgibase.py: cannot find license start
	W: caucase/storage.py: cannot find license start
	W: caucase/test.py: cannot find license start
	W: caucase/utils.py: cannot find license start
	W: caucase/version.py: cannot find license start
	W: caucase/wsgi.py: cannot find license start
	W: setup.py: cannot find license start
	W: shell/caucase.sh: cannot find license start
	W: versioneer.py: no copyright

After:

	W: caucase/_version.py: no copyright
	W: versioneer.py: no copyright

Add FOSS licence exception.
Fix copyright holder name.

...when connection is used as a context manager (which is the expected
coding style anyway).
If silently ignored, rollback may be incomplete if a subtransaction already
committed.
And if commit only happen at outmost transaction, no-undo changes could
come undone if outer transaction aborts.

This is currently observed in the code, so no other change is needed.

What was not picked up by 2to3.

sqlite does not allow controlling creation mode, so create the file
ourselves so it gets created when missing.

While identifiers are integers, they could just as well be treated as
opaque identifiers by external applications.

- Re-evaluate feature set and REST API.
- switch duration units to days, which are more meaningful than sticking to
  ISO units in this context.
- Implement the "cau" half of "caucase".
  As a consequence flask password authentication mechanism is not needed
  anymore. As HTML UI is not required internally to caucase, and as
  sqlalchemy is not used to its full extend, get rid of these
  dependencies altogether.
- Implement REST HTTP/HTTPS stand-alone server as a layer above WSGI
  application, and integrate HTTPS certificate issuance and renewal
  mechanism to simplify deployment: no middleware needed, so from
  gunicorn dependency.
- Use standard python modules for http client needs.
- Re-evaluate data retention options:
  - unsigned CSRs are kept forever
  - CRTs are stored in CSR table, and a 24 hour expiration is set
  - CA CRTs: (unchanged, expire when past validity period)
  - CRLs: (unchanged, expire when past validity period)
- Redispatch housekeeping tasks:
  - CA renewal happens when caucase is used and renewal is needed
  - CRL is flushed when re-generated
  - CSR table (containing CRTs) is cleaned when a new CSR is received
  removing completely the need for these special periodic tasks.
- Storage parameters are not stored persistently anymore, instead their
  effect (time offsets) is applied before storing (to protect against
  transient retention period reconfiguration from wiping data).
- Rework storage schema.
- Implement certificate extension propagation & filtering.
- Implement "Certificate was auto-signed" extension.
- More docstrings.
- Use a CSR as a subject & extensions template instead of only allowing
  to override the subject. Useful when renewing a certificate and when
  authenticated client wants to force (ex) a CommonName in the subject.
- Reorganise cli executable arguments to have more possible actions.
  Especially, make CA renewal systematic on command start (helps
  validating caucase URL).
- Increase the amount of sanity checks against user-provided data (ex:
  do not upload a private key which would be in the same file as the CRT
  to renew).
- Extend package classifiers.
- Get rid of revocation reason, as it seems unlikely to be filled, and
  even less likely to be read later.
- (almost) stop using pyOpenSSL. Use cryptography module instead.
  cryptography has many more features than pyOpenSSL (except for certificate
  validation, sadly), so use it. It completely removes the need to poke
  at ASN.1 ourselves, which significantly simplifies utils module, and
  certificate signature. Code is a bit more verbose when signing, but much
  simpler than before.
- add the possibility to revoke by certificate serial
- update gitignore
- include coverage configuration
- include pylint configuration
- integrate several secondary command:
  - caucase-probe to quickly check server presence and basic
    functionality, so automated deployments can easily auto-check
  - caucase-monitor to automate key initial request and renewal
  - caucase-rerequest to allow full flexibility over certificate request
    content without ever transfering private keys
- add a secure backup generation mechanism
- add a README describing the design

    Split cli_flask functions used to renew, sign and revoke certificate.
    Allow to revoke a certificate by serial PUT /crt/revoke/serial, this
    method required admin authentication. Also add GET /crt/serial/<string:serial>

The certificate authority is used to generate and sign certificate, there is 3 parts:
- web: which contains API to submit certificate signature request and to download signed certificate
- cliweb: which is a command line tool used to quickly generate private key and send certificate signature request, he will
also downlaod automatically the signed certificate as well as ca certificate.
- cli: is used to garbage collect certificate authority, all expired certificate, csr, crl and revocation will be trashed using this tool.

The first csr can be automatically signed, the rest will be signed by the adminitrator, first connection to /admin/ will ask to set password
the admin can see all csr (pending) then sign them. As soon as csr is signed, the client will download (cliweb) the certificate.

client can also renew or revoke his certificate using CA API. Renew and revoke are immediate, there is no admin approval.

on server side, the storage storage.py use sqlite to store all informations (certificat, csr, crl and revocations), there is no use of openssl here.
ca.py will invoke the storage to store or to get certificates.

the client store certificate directly on filesystem, so it can be read by apache, nginx, etc.