HDDS-16035. Secure SCM HA cluster cannot start: the primary SCM refuses to sign certificates for the other SCMs when there is no leader

[ss77892]

What changes were proposed in this pull request?

HDDS-16035. Secure SCM HA cluster cannot start: the primary SCM refuses to sign certificates for the other SCMs when there is no leader

HDDS-16035. Secure SCM HA cluster cannot start: the primary SCM refuses to sign certificates for the other SCMs when there is no leader.
Let a single narrow case skip the leader check: a GetSCMCertificate request that is not a renewal, served by the primary SCM (the one holding the root CA), at a moment when no leader is known. Signing on that path also needs a serial number and a database write, which normally go through Ratis, so it would use a direct serial allocator next to the existing SequenceIdGenerator.upgradeToCertificateSequenceId() and the existing unreplicated storeValidScmCertificate() write that persistPrimarySCMCerts() already uses on every primary start. The current checkValidCertID() check stays, so a repeated serial is refused and never issued, and the path logs a warning so an operator can see it ran. Everything else keeps the leader check: renewals, non-primary SCMs, and OM and datanode certificates. When a leader exists, nothing changes, so this is not a revert of HDDS-8286. It needs no proto change, no new config key, and no interface change. One known gap to note: a certificate signed this way is written only in the primary's local database, which is the same exposure persistPrimarySCMCerts() already has, and each SCM keeps its own certificate on local disk, so startup does not depend on the replicated copy.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-16035

How was this patch tested?

1. UTs for all changed parts (Protocol translator, Leaderless SCM, sequence generator)
2. The situation of the cluster before and after enabling security (Kerberos).