(This ticket is on Fraser's wishlist, but is a potentially
breaking behavioural change in some environments.)

Currently to validate a dnsName SAN, we look for an alternative
principal (of the same service type as the "primary" subject principal).
It is then check for CA ACLs, operator write access to userCertificate attribute,
etc.

e.g. if primary principal is "HTTP/domain1.example.com@EXAMPLE.COM", and the CSR has
a SAN dnsName for "domain2.example.com", then we look for "HTTP/domain2.example.com@EXAMPLE.COM" and, if found, check CA ACLs and write access.

This code is not straightforward, and the notion of adding a new principal
object just so a cert with SANs can be issued is neither intuitive for users nor
lightweight.

Fortunately, we are addressing this in #6295 where SAN processing will become
aware of Kerberos principal aliases.

THIS ticket is about removing the "alternative principal" validation option.
But, note that existing deployments with certs tracked
that used the "alternative principal" validation will experience renewal failures
if we remove this option. It is significant behavioural change and may break
established processes.

I would like to remove it anyway :) I suppose this could get shot down as
wontfix but I think it's worth discussing.