Option to merge the JVM truststore with user-supplied truststore

[thelabdude]

Fixes #390 ~ by allowing the JVM cacerts to get merged in with the user-supplied truststore (Let's Encrypt's CA is in the cacerts for modern JVM)

Users can now configure the TLS options to merge the JVM's truststore with the truststore for their certs using:

spec:
  ...
  solrTLS:
    ...
    trustStoreSecret:
      name: dev-selfsigned-cert-tls
      key: truststore.p12
    mergeJavaTrustStore: "$JAVA_HOME/lib/security/cacerts"

The path given in mergeJavaTrustStore option must exist on the Solr docker image! Thus, if users customize their Solr image, this path may be different.

Behind the scenes, this creates an additional initContainer that merges the two truststores together and then points the env var to the "merged" truststore. The actual merging is done with keytool.

For server TLS:

- name: SOLR_SSL_TRUST_STORE
  value: /var/solr/tls-merged/truststore.p12

By pointing SOLR_SSL_TRUST_STORE env var at the merged truststore, we're ensured that all the other initContainers and liveness probes continue to work (as they just use the env var to resolve this path).

Added a few simple unit tests and tested manually in my cluster.

For Prom exporter, the config would be:

spec:
  solrReference:
    ...
    solrTLS:
      ...
      mergeJavaTrustStore: "$JAVA_HOME/lib/security/cacerts"

Which results in the exporter container getting configed with env var:

- name: SOLR_SSL_CLIENT_TRUST_STORE
  value: /var/solr/tls-merged/truststore.p12

[thelabdude]

I think we should hold off on this solution for 0.6 as now I'm thinking the better approach would be to use the init-db script approach built into the Solr image. The problem with the current solution in this PR is it doesn't work with the mountedTLSDir option. Originally I was thinking the volumes and mounts would be available to the merge initContainer but that's not the case. I think the init-db approach will actually be fairly easy to implement except for the Solr exporter. Unfortunately, I won't have time to work on this for a bit and I don't want to hold up 0.6

[HoustonPutman]

Sounds good Tim. Thanks for putting in the effort on this though!