Migrate tag option filtering from slicing to MoreSearchAdapter

[danotorrey]

Description

Previously, the Tags filter on the Alerts page loaded its values through POST /events/slices, which executes through the views search engine. SearchExecutionGuard there requires streams:read on the events stream itself, so users whose permissions only cover the events' source streams got a 403 and a broken filter.

This adds POST /events/filter_options, which aggregates distinct tag values directly through MoreSearch — the same source-stream-scoped aggregation path already used in production elsewhere — so visibility is determined by the source streams of the events alone.

The endpoint supports server-side search: the dropdown forwards the typed text as field_query, applied as an include pattern on the terms aggregation (case-insensitive contains; tags are lowercase-normalized at write time). The response returns the 50 most-used values; searching reaches values past the cap, and there's intentionally no truncation indicator in the response.

/events/slices is unchanged, and existing callers of MoreSearch.aggregateSlicesForColumn keep their signature via a delegating overload, so no enterprise changes are needed.

Notes

• Ordering is most-used-first (the aggregation's natural order). The event-definitions tags endpoint sorts alphabetically instead — top-used seemed more useful for filtering events, happy to align if preferred.
• Since event tags are unreleased in 7.2, this PR is added to the existing tags changelog entry instead of getting its own.
• I tested this on my local dev setup running master: a reader user shared on a single stream sees only that stream's tags in the dropdown, searching can't surface tags from streams they can't read, and the same user still gets the 403 on the old /events/slices path. Integration tests for the aggregation run against real OpenSearch 2, OpenSearch 3, and Elasticsearch 7 containers.

Fixes Graylog2/graylog-plugin-enterprise#14282

Assisted with Claude Code