fix: operator stability part2

[csatib02]

Overview

• The feature that introduced bridges, was not following the pattern that was set before. This means that now first bridges will be handled from a tenant's perspective:

1. Upon reconciling a tenant, we are checking whether there are bridges deployed in a system that are referencing it.
2. If there are, we add them to tenant.Status.ConnectedBridges.
3. Upon reconciling the collector, we construct the otel-config, by reading the aforementioned field.

• If there are only collectors in the system, dont't even try to create a config, rather just log it.
• Fixed checking bridge's connection: Now we only check if the other end of the bridge is referencing a tenant that is deployed in the system.
• The State of all resources were not updated correctly, therefore running the kubectl get telemetry-all -A command would report false CR states, it is now fixed.

Observations

• It is now very hard (if not impossible) to make TC deploy an instantly failing otel-collector instance.
• TC requires a collection of CR's to be deployed and to be in a ready state at the same time, but due to eventual-consistency the operator will always try to create an otel-config input. It would be great to have a logic that would detect frequent reconcile-requests, so we don't log out unnecessary errors.

[OverOrion]

Overall LGTM, thank you!