Planning for how to manage Slack "Interactivity"

Note: Closing this issue in favor scoping the related requirements to #374957 (closed) & #374957 (closed) / #365366 (closed). The content below may be useful to the implementing engineers, but is not actionable at this time.

Problem to solve

These upcoming Slack slash commands require "interactivity":

• Phase 1: Add `/gitlab incident declare` Slack s... (#344856 - closed)
• Phase 1: Add `/gitlab incident comment <text>` ... (#374957 - closed)
• Phase 1: Add `/gitlab incident timeline <text>`... (#374956 - closed)
• Phase 1: Add `/gitlab incident close` Slack sla... (#374958 - closed)

This means GitLab need to handle web requests triggered by user interactions in Slack, an addition to just slash command triggers. Different slash commands keywords can target different endpoints, but all "interactivity" must target a single endpoint. This may include state changes for a modal, form submissions, button presses, etc.

Note: project-based/high volume dropdown options are handled via a different endpoint - see #374967 (closed)

Options

We can either:

1. Funnel all of these requests to the existing /slack/trigger endpoint in GitLab
2. Create a new endpoint for handling interactivity

Proposal

1. Create a new internal endpoint of slack/interactivity
2. Enable interactivity in Slack App config, pointing to the above URL
3. For a first pass, cache payload/relevant data from each request to track related interactions & return 200 OK

Why?

1. Using a separate endpoint can help manage the longer-running flows within the appropriate context. Different interactions will provide different data, and we'll need to keep track of that. Caching this information (rather than storing chat_data in the DB like pipelines do) lets us automatically expire abandoned data if a form is opened & neglected.
2. Interaction payloads look quick different from slash commands, which means we'll need to do some different types of parsing
3. We'll need to add a separate endpoint for populating dropdowns in Slack, which is yet another payload format. Matching our endpoints up to Slack's structure means we can more directly implement corresponding features.
4. Starting with an internal endpoint will allow us to figure out exactly what the interactions need to look like before locking ourselves into a deprecation process

Open questions

1. Why is slack/trigger a part of the public-facing REST API? Does this new endpoint need to be?
2. Does ~"group::integrations" already have an intention for where this should live?