## Summary
Resolves #179046
Summarize your PR. If it involves visual changes include a screenshot or
gif.

Applies filters based on the selected APM indicator params to the
cardinality count query.

<img width="845" alt="Screenshot 2024-05-10 at 1 07 27 PM"
src="https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec">

### Testing.
1. Create mock api data via `node scripts/synthtrace continuous_rollups
--live`
2. Navigate to create SLI and choose APM latency
3. Select a service
4. Select group by as `service.name`. Cardinality count should be 1
5. Select environment all and change the group by to
`service.environment`. Cardinality count should be 2.
6. Now select a specific environment. Notice cardinality count changes
to 1.
7. Repeat this testing strategy with transaction name and transaction
type, changing the group by field to `transaction.name` or
`transaction.type`, respectively and playing around with the ALL_VALUE
versus a specific value.
8. Also make sure to test the global filter for regressions

### Release note
The cardinality count for SLOs generated from a single SLI definition
was previously incorrect for APM latency and APM availability SLIs. The
cardinality count is now accurate.

## Summary
Resolves elastic#179046
Summarize your PR. If it involves visual changes include a screenshot or
gif.

Applies filters based on the selected APM indicator params to the
cardinality count query.

<img width="845" alt="Screenshot 2024-05-10 at 1 07 27 PM"
src="https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec">

### Testing.
1. Create mock api data via `node scripts/synthtrace continuous_rollups
--live`
2. Navigate to create SLI and choose APM latency
3. Select a service
4. Select group by as `service.name`. Cardinality count should be 1
5. Select environment all and change the group by to
`service.environment`. Cardinality count should be 2.
6. Now select a specific environment. Notice cardinality count changes
to 1.
7. Repeat this testing strategy with transaction name and transaction
type, changing the group by field to `transaction.name` or
`transaction.type`, respectively and playing around with the ALL_VALUE
versus a specific value.
8. Also make sure to test the global filter for regressions

### Release note
The cardinality count for SLOs generated from a single SLI definition
was previously incorrect for APM latency and APM availability SLIs. The
cardinality count is now accurate.

(cherry picked from commit d3945a3)

# Backport

This will backport the following commits from `main` to `8.14`:
- [[SLOS] fix APM group by cardinality count
(#183171)](#183171)

<!--- Backport version: 9.4.3 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Dominique
Clarke","email":"dominique.clarke@elastic.co"},"sourceCommit":{"committedDate":"2024-05-14T18:45:38Z","message":"[SLOS]
fix APM group by cardinality count (#183171)\n\n## Summary\r\nResolves
#179046 your PR. If
it involves visual changes include a screenshot
or\r\ngif.\r\n\r\nApplies filters based on the selected APM indicator
params to the\r\ncardinality count query.\r\n\r\n<img width=\"845\"
alt=\"Screenshot 2024-05-10 at 1 07 27
PM\"\r\nsrc=\"https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec\">\r\n\r\n###
Testing.\r\n1. Create mock api data via `node scripts/synthtrace
continuous_rollups\r\n--live`\r\n2. Navigate to create SLI and choose
APM latency\r\n3. Select a service\r\n4. Select group by as
`service.name`. Cardinality count should be 1\r\n5. Select environment
all and change the group by to\r\n`service.environment`. Cardinality
count should be 2.\r\n6. Now select a specific environment. Notice
cardinality count changes\r\nto 1.\r\n7. Repeat this testing strategy
with transaction name and transaction\r\ntype, changing the group by
field to `transaction.name` or\r\n`transaction.type`, respectively and
playing around with the ALL_VALUE\r\nversus a specific value.\r\n8. Also
make sure to test the global filter for regressions\r\n\r\n### Release
note\r\nThe cardinality count for SLOs generated from a single SLI
definition\r\nwas previously incorrect for APM latency and APM
availability SLIs. The\r\ncardinality count is now
accurate.","sha":"d3945a3e50eaad9f850bb4d88863e6a91026acbc","branchLabelMapping":{"^v8.15.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","Feature:SLO","ci:project-deploy-observability","Team:obs-ux-management","v8.14.0","v8.15.0"],"title":"[SLOS]
fix APM group by cardinality
count","number":183171,"url":"#183171
fix APM group by cardinality count (#183171)\n\n## Summary\r\nResolves
#179046 your PR. If
it involves visual changes include a screenshot
or\r\ngif.\r\n\r\nApplies filters based on the selected APM indicator
params to the\r\ncardinality count query.\r\n\r\n<img width=\"845\"
alt=\"Screenshot 2024-05-10 at 1 07 27
PM\"\r\nsrc=\"https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec\">\r\n\r\n###
Testing.\r\n1. Create mock api data via `node scripts/synthtrace
continuous_rollups\r\n--live`\r\n2. Navigate to create SLI and choose
APM latency\r\n3. Select a service\r\n4. Select group by as
`service.name`. Cardinality count should be 1\r\n5. Select environment
all and change the group by to\r\n`service.environment`. Cardinality
count should be 2.\r\n6. Now select a specific environment. Notice
cardinality count changes\r\nto 1.\r\n7. Repeat this testing strategy
with transaction name and transaction\r\ntype, changing the group by
field to `transaction.name` or\r\n`transaction.type`, respectively and
playing around with the ALL_VALUE\r\nversus a specific value.\r\n8. Also
make sure to test the global filter for regressions\r\n\r\n### Release
note\r\nThe cardinality count for SLOs generated from a single SLI
definition\r\nwas previously incorrect for APM latency and APM
availability SLIs. The\r\ncardinality count is now
accurate.","sha":"d3945a3e50eaad9f850bb4d88863e6a91026acbc"}},"sourceBranch":"main","suggestedTargetBranches":["8.14"],"targetPullRequestStates":[{"branch":"8.14","label":"v8.14.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.15.0","branchLabelMappingKey":"^v8.15.0$","isSourceBranch":true,"state":"MERGED","url":"#183171
fix APM group by cardinality count (#183171)\n\n## Summary\r\nResolves
#179046 your PR. If
it involves visual changes include a screenshot
or\r\ngif.\r\n\r\nApplies filters based on the selected APM indicator
params to the\r\ncardinality count query.\r\n\r\n<img width=\"845\"
alt=\"Screenshot 2024-05-10 at 1 07 27
PM\"\r\nsrc=\"https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec\">\r\n\r\n###
Testing.\r\n1. Create mock api data via `node scripts/synthtrace
continuous_rollups\r\n--live`\r\n2. Navigate to create SLI and choose
APM latency\r\n3. Select a service\r\n4. Select group by as
`service.name`. Cardinality count should be 1\r\n5. Select environment
all and change the group by to\r\n`service.environment`. Cardinality
count should be 2.\r\n6. Now select a specific environment. Notice
cardinality count changes\r\nto 1.\r\n7. Repeat this testing strategy
with transaction name and transaction\r\ntype, changing the group by
field to `transaction.name` or\r\n`transaction.type`, respectively and
playing around with the ALL_VALUE\r\nversus a specific value.\r\n8. Also
make sure to test the global filter for regressions\r\n\r\n### Release
note\r\nThe cardinality count for SLOs generated from a single SLI
definition\r\nwas previously incorrect for APM latency and APM
availability SLIs. The\r\ncardinality count is now
accurate.","sha":"d3945a3e50eaad9f850bb4d88863e6a91026acbc"}}]}]
BACKPORT-->

Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>