[Fleet]: The agent count is not consistent while adding integration to multiple policies

[muskangulati-qasource]

Kibana Build details:

VERSION: 8.16.0 SNAPSHOT
BUILD: 77286
COMMIT: dcb16775f8192c2fc8ce629999da779e8b894413

Preconditions:

1. 8.16.0 SNAPSHOT Kibana cloud environment should be available.
2. Multiple agents should be deployed
3. A few agents should be offline
   For instance: 5 agents were deployed on the environment, out of which 2 were offline (shutoff)

Steps to reproduce:

1. Navigate to Integration>OSQuery
2. Click Add OS Query integration>Existing agent policies>select multiple integrations including policies with offline and online agents
3. Observe the count of the agents mentioned under the policies section
4. Save the integration
5. Observe the count is different from the total count.

Expected Result:
The count should be consistent. Either all agents count should be visible or just the online agents count should be displayed

Screen Recording:

Multiple.policies.mp4

Feature:
#75867

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[muskangulati-qasource]

@amolnater-qasource please review!

[amolnater-qasource]

Secondary Review for this ticket is Done.

[jen-huang]

@kpollich @nimarezainia We've always had trouble with agent count in multiple modals and recent big changes have just added to the complexity, not to mention issues due to agent policies at scale. I'm not sure if the value add justifies this complexity. I suggest looking at #190432 broadly before tackling this specific bug (if we still wish to tackle it).

[nimarezainia]

@jen-huang we can have a broader discussion on the agent counts you mention. In this case however, are we not reporting the correct number? 5 are enrolled (1st modal), out of which 2 are offline. We send update to 3 that are healthy (last modal). isn't this correct?

on a side note, definitely would like to see #190432 prioritized above this issue.

[kpollich]

Thanks folks. I'm going to close this as not planned in favor of rethinking agent counts more broadly. I've placed #190432 in an upcoming sprint for technical definition.