[Backend] Add aggregations for work items by status_name

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem to solve

Supporting the work items custom status implementation for advanced search: &17575 (comment 2480612473)

The frontend must allow the user to filter work items by custom status. To support this the backend must provide a list of used custom_status names in the search results

Proposal

At the time of writing this issue, there is no documentation on how to add new aggregations in the advanced search development guide: https://docs.gitlab.com/development/advanced_search/#updating-an-existing-scope. However, it might have been added as we work on other features so check there first

This will require a change to how the WorkItemQueryBuilder uses aggregations. Currently the options field takes in options[:aggregation]=true and only supports one aggregation (by label). The builder framework will need to support 0 or more aggregations.

The aggregations endpoint will need to support sending back more than 1 aggregation in the response. Currently it assumes one

• Add a new aggregation to Search::Elastic::Aggregation named by_custom_status
• Add support to the Search::AggregationParser for the new aggregation
• Change Gitlab::Elastic::SearchResults#issue_aggregations to send which aggregations to return.
  • something like this option[aggregations: [:label, :custom_status] would allow one aggregation call for issues to return all aggregations supported by the index in one call
  • the builder can then apply the correct aggregation to the query
• Update related specs and documentation