ATLAS-5362: fix Solr Kerberos client + SSL cipher list parsing for AMRA

[saksenasonali]

Two fixes found while deploying the AMRA (ATLAS-5362) WAR on a Kerberos+TLS CDP cluster running on JDK 17:

1. Solr6Index did not configure SolrJ for Kerberos, so index bootstrap (e.g. vertex_index) failed with HTTP 401 from a Kerberized Solr. Register Krb5HttpClientBuilder at class load (before any SolrClient is built) when a JAAS login config is present, so SolrJ performs SPNego negotiation using the 'Client' JAAS entry.

2. SecureEmbeddedServer read atlas.ssl.enabled.algorithms via Configuration.getList(), which only splits on ','. Existing CDP/CDH configs are ':'-delimited, so the entire joined string was treated as a single (invalid) cipher name and the TLS listener started with zero usable ciphers (handshake failed / SSL_ERROR_ZERO_RETURN). Split each entry on both ':' and ',' so both delimiters are honored.

What changes were proposed in this pull request?

Two targeted fixes on top of the AMRA (ATLAS-5362) branch, discovered while deploying the AMRA WAR to a Kerberos + auto-TLS CDP cluster on JDK 17. Both are backward-compatible and only change behavior on Kerberized / TLS-enabled clusters.

1. graphdb/janus/.../solr/Solr6Index.java — register SolrJ Kerberos client (+1 import, +14 lines)

• Added import org.apache.solr.client.solrj.impl.Krb5HttpClientBuilder;
• Added a static initializer that, when java.security.auth.login.config is set (i.e. Kerberos is in effect), calls HttpClientUtil.setHttpClientBuilder(new Krb5HttpClientBuilder().getBuilder()) before any SolrClient is constructed.
• This makes SolrJ perform SPNego negotiation using the Client JAAS entry, so the JanusGraph index bootstrap (e.g. vertex_index) no longer fails with HTTP 401 against a Kerberized Solr. The JAAS app name remains configurable via -Dsolr.kerberos.jaas.appname (default Client).

2. server-common/.../service/SecureEmbeddedServer.java — tolerate ':'-delimited cipher lists (+24 / -1 lines)

• config.getList(ATLAS_SSL_ENABLED_ALGORITHMS) from commons-configuration only splits on ','. Legacy CDP/CDH deployments supply atlas.ssl.enabled.algorithms as a ':'-delimited string, so the whole joined value was treated as one bogus cipher name → the TLS listener started with zero usable ciphers and every HTTPS handshake failed.
• Now each returned entry is split on both : and , (split("[,:]")), trimmed, and empty tokens are dropped, before calling setIncludeCipherSuites(...). Comma-only lists continue to work unchanged.

No new config keys, no API changes; both changes are no-ops on non-Kerberos / comma-delimited-cipher clusters.

How was this patch tested?

Manual, end-to-end on a real cluster (quasar-towojm, CDP 7.3.2, Kerberos + auto-TLS, Atlas on JDK 17):

• Built the AMRA branch WAR (PR ATLAS-5362: Atlas Modular Runtime Architecture — Service Decomposition, Graph-Native Coordination, Active-Active HA, and RunMode-Driven Execution apache/atlas#711 head 9548b54) with these two fixes applied and deployed it to a 2-node Atlas topology (dual-ACTIVE: METADATA_SERVER + NOTIFICATION_PROCESSOR).
• Fix 1: Before the change, JanusGraph/Solr index bootstrap failed with HTTP 401 (Unauthorized) from Kerberized Solr. After the change, vertex_index and the other Solr collections bootstrap cleanly and both Atlas nodes reach Status: ACTIVE.
• Fix 2: Before the change, HTTPS on the Atlas port failed the TLS handshake (SSL_ERROR_ZERO_RETURN, zero enabled ciphers). After the change, curl -k https://<host>:31443/api/atlas/admin/status and /admin/version return 200 with Status: ACTIVE and the correct build Revision.
• Ran the Atlas QE AMRA system-test suite (430 collected tests) against this deployment; Atlas came up and served REST on both roles.