Service Map: Add aggregations and query filters to use in service map queries

[idastambuk]

Service Map feature: Add aggregations and query filters to use in service map queries

We're using some new aggregation types (openSeachQuery.aggs) and query filters (openSearchQuery.query) in requests for service map data to Open search.

Query filters are what Open Search will filter the documents by, before applying the aggregations to the filtered set.

Query filters:

• MustNotFilters
• ShouldFilters (functions as OR for conditions inside it)
• Terms/Term filter (they must get marshaled differently depending on whether they have one or multiple values

Aggregations:

• Script aggregation
• Terms aggregation (different than Terms filter) aggregating by term (field) serviceName

Also:

• tests
• renamed MustQueryBuilder to FilterList, as this struct wasn't Must-specific

Note:

The Bool filters that we need to add in order to get the right stats for the service map are quite nested and look a bit messy. This is because filter, must _not, must... filters always need to be nested under the bool filter, so there's a lot of repetition in the nesting. Once we start using them, we will need to have a complex query that looks like this:

What this PR does / why we need it:
Part of the service map feature

Special notes for your reviewer:
Not using them in main, but they will be used in subsequent PRs for Service map

[iwysiu]

Nice! Some style nits

[iwysiu]

We can remove the else and just make this a return

[idastambuk]

True, but I feel like adding the else explicitly is more readable 🤔

[iwysiu]

This is a short enough function that it doesn't really matter, but generally, the go style convention is to avoid having final returns in elses, and golint actually will format your code that way (though we don't have golint turned on in our repos). Basically the idea for readability is that your functions are always returning at the end with the general behavior as left justified as possible, with exceptions branching off with an if (splitting off into sub functions if really necessary).
(My old mentor's position was that you should never have an else in your go code ever, and while I'm not that extreme I do see his point that it ends up with a lot of different behavior paths that are easy to lose bugs in)
(Also If you want to read people talking about it on reddit here's a link, lol)

[katebrenner]

fixes #371