Fix target allocator readiness check

[swiatekm]

Description:
The target allocator readiness check is broken in two ways:

• The target allocator doesn't do an initial load of targets from Prometheus CRs. So if there aren't any CRs, no targets are generated.
• If there are no scrape configs, but there is an empty scrape configs array, targets are loaded from these, and the target allocator becomes ready even though it shouldn't be.

This PR fixes both of these issues by:

• Loading targets from Prometheus CRs at startup.
• Not loading targets from scrape configs if there aren't any.
• For good measure, the target allocator config now doesn't even have the prometheus configuration section if there aren't any scrape targets.

Link to tracking Issue(s): #2903

• Resolves: Target allocator never becomes ready if only Prometheus CRs are enabled, and there aren't any defined #2903

Testing:
I changed an integration test with only Prometheus CR enabled to run without any actual CRs created initially.

[jaronoff97]

this is done below in the rungroup which should be run once when it's first loaded. Do we need to also do it out here?

[jaronoff97]

i.e. it's fine to do the load config here, but couldn't we just set it as cfg.PromConfig and let the rungroup handle the call?

[swiatekm]

We can't in general, because cfg.PromConfig might not be empty. I could move it into the rungroup which established the Prometheus CR Watcher, if you think that'd be cleaner.

[swiatekm]

The calls look similar, but they actually refer to different event sources.

[jaronoff97]

oh i see that now, yes. I wonder if we should just send a message to the events channel to force an initial refresh rather than making new calls here?

[jaronoff97]

@swiatekm-sumo and I discussed a different approach where we just send the event for the channel which for now is going to make the config loading fail silently to a user which seems not ideal.