Allow x509 Service CA implementation to be injected through ca and authority options

[venkyg-sec]

Name of feature:

Dependency injection of an externally implemented X509 CA.

Pain or issue this feature alleviates:

Step-ca currently supports 3 types of X509 CA implementations (Vault CA, another Step-CA or Google Cloud CA). For folks who have their own CA implementation and protocol, there's no flexibility to inject such custom code. This PR makes small additions to the Options for CA and Authority and allows the Application to provide a custom X509 CA Service interface.

Is there documentation on how to use this feature? If so, where?

Not yet - but happy to update the sample application in this repository, include tests and include documentation if this feature is of interest.

In what environments or workflows is this feature supported?

Anyone using step-ca as an integrated library

Test

venkyg@venkyg-fedora-PC2HVLQL:~/certificates$ make test
✓  acme (3.249s) (coverage: 64.1% of statements)
✓  acme/api (142ms) (coverage: 92.4% of statements)
✓  acme/db/nosql (11ms) (coverage: 97.0% of statements)
✓  api/log (2ms) (coverage: 52.9% of statements)
∅  api/models
✓  api/render (2ms) (coverage: 83.7% of statements)
✓  api/read (3ms) (coverage: 100.0% of statements)
∅  authority/admin
∅  authority/administrator
✓  authority/admin/db/nosql (17ms) (coverage: 94.8% of statements)
✓  authority/admin/api (25ms) (coverage: 88.3% of statements)
✓  authority/policy (7ms) (coverage: 41.7% of statements)
✓  authority/internal/constraints (8ms) (coverage: 81.6% of statements)
✓  authority/config (15ms) (coverage: 67.5% of statements)
✓  authority (731ms) (coverage: 46.0% of statements)
✓  cas (3ms) (coverage: 95.0% of statements)
✓  cas/apiv1 (4ms) (coverage: 97.4% of statements)
✓  ca/identity (31ms) (coverage: 93.3% of statements)
✓  cas/cloudcas (112ms) (coverage: 96.4% of statements)
✓  api (5.26s) (coverage: 76.9% of statements)
✓  cas/softcas (765ms) (coverage: 91.3% of statements)
∅  cmd/step-ca
∅  commands
✓  cas/vaultcas/auth/kubernetes (9ms) (coverage: 87.5% of statements)
✓  cas/vaultcas/auth/approle (11ms) (coverage: 86.4% of statements)
✓  cas/vaultcas (18ms) (coverage: 79.7% of statements)
∅  examples/basic-client
∅  examples/basic-federation/client
∅  examples/basic-federation/server
✓  errs (3ms) (coverage: 7.6% of statements)
✓  db (8ms) (coverage: 26.5% of statements)
∅  examples/bootstrap-client
∅  examples/bootstrap-mtls-server
∅  examples/bootstrap-tls-server
∅  monitoring
✓  logging (7ms) (coverage: 30.6% of statements)
∅  scripts/badger-migration
∅  server
✓  scep/api (26ms) (coverage: 27.4% of statements)
✓  policy (47ms) (coverage: 93.0% of statements)
✓  pki (208ms) (coverage: 33.8% of statements)
✓  scep (211ms) (coverage: 5.0% of statements)
✓  webhook (2ms) (coverage: 71.1% of statements)
✓  templates (8ms) (coverage: 93.5% of statements)
✓  cas/stepcas (3.556s) (coverage: 93.9% of statements)
✓  authority/provisioner (14.574s) (coverage: 79.0% of statements)
✓  ca (26.841s) (coverage: 43.0% of statements)

DONE 4352 tests in 40.318s
✓  acme (5.286s) (coverage: 73.0% of statements)

DONE 302 tests in 7.218s

💔Thank you!

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[maraino]

Thanks @venkyg-sec, lgtm.

I've fixed the linter error in your repo and resolved the merge conflict.