What's in this PR?

A limitation with the current implementation is that the user identities and service names can become too long depending on your namespace name and cluster domain. If this string is over 64 bytes, cert manager is unable to create certificates. This is a show stopper issue for us because we cannot change our cluster domains.

This PR allows admin and node user identities to be set to custom values. And it allows service names templates to be overriden.

Four properties added to the NifiCluster spec:

• headlessServiceTemplate: instead of the default template %s-headless you can provide an alternative, such as %s-h
• nodeControllerTemplate: instead of the default template %s-controller you can provide an alternative, such as %s-c
• nodeUserIdentityTemplate: instead of the default dynamic node user identity which is very long, you can provide an alternative for a shorter identity, such as node-%d-user which becomes node-1-user, node-2-user, etc.
• adminUserIdentity: instead of the default dynamic admin user identity which is very long, you can provide an alternative, such as admin-user

Default behavior is unchanged from the current implementation. None of these new properties are required.

Why?

This PR unblocks teams who have longer cluster domains and want to use a cert-manager integration. Those teams can opt-in to using these four new properties in the NifiCluster spec to shorten the user identities and service names.

I decided to take the implementation path seen here since it did not drift from the current implementation too much. Basically instead of hardcoding the HeadlessServiceTemplate and NodeControllerTemplate, they can now be overridden by a provided property. The adminUserIdentity is shared across all the nodes so it can be a static value with any name the user would like. However, the nodeUserIdentityTemplate must be unique per node therefore the user needs to provide a template so we can populate the node's ID in the user's identity.

Additional context

Checklist

• Implementation tested
• Error handling code meets the guideline
• Logging code meets the guideline
• User guide and development docs updated (if needed)
• Append changelog with changes