Use Elasticsearch for all Vulnerability Report filtering and grouping when ES is available
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=547510) </details> <!--IssueSummary end--> <!--Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan--> ## Why are we doing this work Phase 1 of https://gitlab.com/groups/gitlab-org/-/epics/13510+ included using Elasticsearch for filtering and grouping only when Identifier and OWASP 2021 are used. The API auto-selects the datasource (PG or ES) based on the inclusion of these specific query fields. This issue tracks changing the data resolver to use Elasticsearch aways, when it's available to the instance and the `accessAdvancedVulnerabilityManagement` ability feature flag is enabled. ## Relevant links <!--Information that the developer might need to refer to when implementing the issue. - [Design Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>) - [Design 1](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png) - [Similar implementation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<id>)--> ## Non-functional requirements <!--Add details for required items and delete others.--> - [ ] Documentation: - [ ] Feature flag: - [ ] Performance: - [ ] Testing: ## Implementation plan For both Project and Group Vulnerability Reports 1. ~backend Update GraphQL resolver for [project.vulnerabilitySeverityCount](https://docs.gitlab.com/api/graphql/reference/#projectvulnerabilityseveritiescount) and [group.vulnerabilitySeverityCount](https://docs.gitlab.com/api/graphql/reference/#groupvulnerabilityseveritiescount) to use Elasticsearch as the datasource when ES is available and `accessAdvancedVulnerabilityManagement` is enabled. 2. ~backend For both APIs, dd a new response field `useFullSeverityCounts:bool` when the condition above exists. 3. ~frontend When `useFullSeverityCounts` is `true`, the frontend will display the full, not-fuzzy counts. ## Verification steps <!--Add verification steps to help GitLab team members test the implementation. This is particularly useful during the MR review and the ~"workflow::verification" step. You may not know exactly what the verification steps should be during issue refinement, so you can always come back later to add them. 1. Check-out the corresponding branch 1. ... 1. Profit!-->
issue