Allow disabling NiFi 2.x SNI checks

[Maleware]

Part of #809.

The SNI hostname checks appear to exist so that accidentally hitting the wrong node cannot happen.

We have opened an upstream issue and PR to allow to make this configurable:

• Upstream issue: https://issues.apache.org/jira/browse/NIFI-14858
• Upstream PR (rejected) NIFI-14858: Make SNI checking configurable apache/nifi#10201
• Docker image patch: Backport NIFI-14858 to NiFi 2.4.0 docker-images#1225
• Documentation change: docs: Document workaround to disable SNI checks #834

The upstream PR has been rejected but we still believe it is the correct solution and does not have a noticeable impact on security. And it is opt-in so we'll allow disabling SNI.

Tasks:

• Make SNI configurable (see above)
• Update NiFi documentation: https://docs.stackable.tech/home/stable/nifi/troubleshooting/#_http_error_400_invalid_sni
• Consider adding a CRD flag to disable the SNI check

Related material:

• https://medium.com/@chnzhoujun/how-to-resolve-sni-issue-when-upgrading-to-nifi-2-0-907e07d465c5
• https://docs.stackable.tech/home/stable/nifi/troubleshooting/#_http_error_400_invalid_sni
• https://issues.apache.org/jira/browse/NIFI-14353
• https://issues.apache.org/jira/browse/NIFI-14209

[lfrancke]

We had a preliminary discussion around this today and the consensus so far was to include this as a field in the CRD.

The next steps therefore are for someone to propose a CRD structure, create a decision and then implement this CRD change.

Naively I could think of putting it under the tls field but I'm not sure if that's a common struct.
Also: We need to consider the hostHeaderCheck field and its corresponding documentation.
https://crds.stackable.tech/25.7.0/nifi.stackable.tech/nificluster/v1alpha1/#spec-clusterConfig-hostHeaderCheck

I found out about this too late before my vacation and I'm not sure if this is still needed with the SNI check or not.