Insights operator does not respect disableInsightsAlerts in RHOCP 4.14.z    

4.14.z    

It's kind of a race condition. The trick to reproduce that is to immediately delete/restart the operator's Pod when the "support" secret (with the attribute) is created.
    

    1. Disable insights alerts using documentatio[a]
    2. immediately delete/restart the operator's Pod when the "support" secret (with the attribute) is created

[a] https://docs.openshift.com/container-platform/4.14/support/remote_health_monitoring/using-insights-operator.html#disabling-insights-operator-alerts_using-insights-operator
    

After setting "disableInsightsAlerts": true, the customer has not reported any new Insights alerts but still sees the following in the OpenShift Console
```
InsightsDisabled
Sep 24, 2024, 11:14 AM
Insights operator is disabled. In order to enable Insights and benefit from recommendations specific to your cluster, please follow steps listed in the documentation:
https://docs.openshift.com/container-platform/latest/support/remote_health_monitoring/enabling-
remote-health-reporting.html
```
    

In the bug https://issues.redhat.com/browse/OCPBUGS-13915 discussion, it was clarified that the current logic should prevent any Insights alerts (including "InsightsDisabled" and "SimpleContentAccessNotAvailable") when disableInsightsAlerts is set to true. Yet, the customer's experience still reflects the older logic.    

Tomas Remes, who worked in OCPBUGS-13915, was able to reproduce it and requested to open a new OCPBUG with following msg 
```
Thank you. I was finally able to reproduce it, so yes it's a bug. It's kind of a race condition. The trick to reproduce that is to immediately delete/restart the operator's Pod when the "support" secret (with the attribute) is created. I think it would be better to create a new OCPBUG. What do you think please?
```