pki: use library-go crypto for cert generation

[sanchezl]

Context

This is a review/refactoring of openshift#10396 that migrates the installer's cert generation to use library-go/pkg/crypto and library-go/pkg/pki instead of hand-rolling crypto primitives.

@hasbro17 — I went through your PR in detail and wanted to suggest an alternative approach that aligns the installer with the same cert generation APIs that other operators are adopting (CKAO via openshift/cluster-kube-apiserver-operator#2087, service-ca-operator via openshift/service-ca-operator#327). Here's why I made each change:

Why library-go instead of hand-rolled crypto

Your PR adds GeneratePrivateKeyWithParams, GenerateECDSAPrivateKey, GenerateRSAPrivateKey, keyUsageForAlgorithm, PKIConfigToKeyParams, and changes PrivateKeyToPem/PemToPrivateKey to handle both RSA and ECDSA. All of this already exists in library-go/pkg/crypto (after openshift/library-go#2127):

What your PR does manually	library-go equivalent
GeneratePrivateKeyWithParams(params)	KeyPairGenerator.GenerateKeyPair() via RSAKeyPairGenerator{Bits} or ECDSAKeyPairGenerator{Curve}
keyUsageForAlgorithm(algo)	KeyUsageForPublicKey(pub)
GenerateSelfSignedCertificate(cfg, params)	NewSigningCertificate(name, keyGen, opts...)
PrivateKeyToPem(key) / CertToPem(cert)	TLSCertificateConfig.GetPEMBytes() / EncodeKey()
generateSubjectKeyID(pub) (SHA-1)	SubjectKeyIDFromPublicKey(pub) (SHA-256, FIPS-compatible)

Additionally, library-go/pkg/pki provides:

• DefaultPKIProfile() — replaces the local copy
• KeyPairGeneratorFromAPI(keyConfig) — converts configv1alpha1.KeyConfig → KeyPairGenerator
• ResolveCertificateConfig(provider, certType, name) — resolves effective key config per certificate type and name, matching how CKAO and service-ca-operator resolve their configs

Why local PKI types instead of embedding configv1alpha1

Your PR embeds configv1alpha1.CertificateConfig directly in types.PKIConfig. This means if CertificateConfig gains new fields upstream (e.g., SignatureAlgorithm, Extensions), they'd silently appear in the install-config YAML API without the installer explicitly opting in or validating them.

I replaced this with installer-local types (types.CertificateConfig, types.KeyConfig, types.RSAKeyConfig, types.ECDSAKeyConfig) that mirror only the fields we support. Conversion to upstream API types happens at the boundary when building the PKI CR manifest.

Why SignerPKIConfig as an asset

Your PR has each signer call pkidefaults.EffectiveSignerPKIConfig(installConfig.Config) independently. This means every signer resolves the same config from InstallConfig, and the PKI manifest does the same resolution separately.

I introduced a SignerPKIConfig asset in the dependency graph that resolves the effective PKIProfile once. All signers and the PKI manifest depend on it. The profile is never nil — feature gate off returns explicit RSA 2048, feature gate on returns libpki.DefaultPKIProfile() with user overrides. This eliminates nil-check branching everywhere.

Why EffectiveSignerPKIProfile returns PKIProfile (not *PKIConfig)

Your EffectiveSignerPKIConfig returns *types.PKIConfig (nullable). The new EffectiveSignerPKIProfile returns configv1alpha1.PKIProfile (never nil). This:

• Eliminates nil checks and the "legacy RSA 2048" branch in every signer
• Returns the upstream type directly, so the PKI manifest can use it without conversion
• Includes both Defaults (for leaf certs) and SignerCertificates, enabling leaf certs to also follow the profile

Why leaf certs also migrate

Your PR deliberately left leaf certs using RSA 2048. This refactoring migrates them too — when ConfigurablePKI is enabled, leaves follow the profile's Defaults (ECDSA P-256). This is consistent with how the library-go PKI profile system works and what the cluster operators expect.

Each leaf cert now has an explicit CertificateType field (serving/client/peer) and resolves its key algorithm via libpki.ResolveCertificateConfig.

Why certificate names

Each cert gets a name string (e.g., "kube-apiserver.kubelet-client-signer") passed to ResolveCertificateConfig. These match the CertificateName strings being adopted in CKAO (openshift/cluster-kube-apiserver-operator#2087) and service-ca-operator (openshift/service-ca-operator#327), and are cross-referenced against the TLS artifact registry in openshift/origin.

What's preserved from your PR

• The pki field on InstallConfig and its feature gating
• Validation logic (updated for local types)
• The PKI CR manifest generation (simplified via SignerPKIConfig)
• BoundSASigningKey RSA enforcement
• IronicTLSCert left as-is (non-CA self-signed, special case)

What's deleted

• ~200 lines of hand-rolled crypto in tls.go (GeneratePrivateKeyWithParams, GenerateRSAPrivateKey, GenerateECDSAPrivateKey, keyUsageForAlgorithm, PKIConfigToKeyParams, PrivateKeyParams)
• ~80 lines of forked crypto in configimage/ingressoperatorsigner.go
• Local DefaultPKIProfile() copy (replaced by library-go/pkg/pki import)

Test plan

• go test ./pkg/asset/tls/... — all pass
• go test ./pkg/types/pki/... — all pass
• go test ./pkg/types/validation/... — all pass
• go test ./pkg/asset/manifests/... — all pass
• go test ./pkg/asset/imagebased/configimage/... — all pass
• go build ./pkg/... ./cmd/... — clean build
• e2e with ConfigurablePKI enabled