Add-AzServiceFabricClusterCertificate: Add support for new certificate with same common name

[jcleavel]

Description

Currently, the Add-AzServiceFabricClusterCertificate cmdlet fails to add a new certificate to the cluster if the supplied common name is the same as the one currently installed on the cluster. This does not align with how Service Fabric handles common name-based certificate rotation.

Cmdlet argument example:

Add-AzServiceFabricClusterCertificate `
    -ResourceGroupName 'cluster-rg' `
    -Name 'fake-cluster' `
    -SecretIdentifier 'https://VAULT-NAME.vault.azure.net/secrets/CERT-NAME/VERSION' `
    -CertificateIssuerThumbprint 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' `
    -CertificateCommonName 'common-name.fake-u.rl'

The cmdlet fails to run for the following reasons:

• A tangentially-related NullReferenceException would throw when the cmdlet is called on cluster without a certificate object in its resource properties. This object isn't necessary in clusters secured with common name-referenced certificates. Fixed by adding appropriate null handling and correcting what criteria constitute a "Secure" cluster.
• The ARM API would reject a PATCH operation to the cluster resource if the new certificateCommonNames.commonNames[] array contained multiple items with the same value in the certificateCommonName property. Fixed by de-duping and overwriting the duplicate value with the incoming value(s).

The following problematic but non-fatal behavior was also corrected:

• The cmdlet would add duplicate values to the settings.certificate.commonNames[] array on the cluster VMSS's respective Service Fabric VMSS Extensions. This doesn't appear to cause a problem, but it's definitely confusing and messy. Fixed by case-insensitive de-duping.

Checklist

• I have read the Submitting Changes section of CONTRIBUTING.md
• The title of the PR is clear and informative
• The appropriate ChangeLog.md file(s) has been updated:
  • For any service, the ChangeLog.md file can be found at src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md
  • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header -- no new version header should be added
• The PR does not introduce breaking changes
• If applicable, the changes made in the PR have proper test coverage
• For public API changes to cmdlets:
  • a cmdlet design review was approved for the changes in this repository (Microsoft internal only)
  • the markdown help files have been regenerated using the commands listed here