Remove product_stage leftovers

Remove internal events generator

Instead of asking the user to input section, stage and group
we now only require group.

The provided group is validated against:
https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml

Add period Redis metrics to generator

Add milestone, which was missed in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133865.

Adds support code to start requiring milestones as well as including the
current milestone when generating a new migration.

Update some failing tests

Slight updates

We use Internal Events Tracking framework now, so the old code can be removed

Changelog: removed

MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/133436

Changelog: added

Migrate EE issue events to GIET

This adds a new data_source for metrics for use with internal events
tracking, which combines firing both Redis HLL and Snowplow events
associated with the metric at the same time.

In the generator folder we have few templates which we are using for migration and post migration.
As it contains the ERB codebase the files are having a .rb extension instead of .rb.tt
To solve this problem, replace the .rb files within https://gitlab.com/gitlab-org/gitlab/=/tree/master/generator_templates to .rb.tt

Changelog: other

Add new rails generator that creates configuration files for
gitlab internal events tracking feature.

Add new rails generator that creates configuration files for
gitlab internal events tracking feature.

This does the following changes:

- Add documentation for migrations for multiple databases.
- This makes the migrations using a new style being a default
  (not yet mandatory).
- This updates all exceptions and other documentation places
  to include link to migration docs.
- Create `MigrationRecord` as a base class for migrations

This introduces a versioned parent class for database migrations.

This implements a simple versioning scheme for migration helpers.

We need to be able to version helpers, so we can change their behavior
without altering the behavior of already existing migrations in
incompatible ways.

We can continue to change the behavior of helpers without bumping the
version here, *if* the change is backwards-compatible.

If not, we would typically override the helper method in a new
MigrationHelpers::V[0-9]+ class and create a new entry with a bumped
version below.

We use major version bumps to indicate significant changes and minor
version bumps to indicate backwards-compatible or otherwise minor
changes (e.g. a Rails version bump). However, this hasn't been
strictly formalized yet.

Changelog: other

Switches from Rails classic autoloader to Zeitwerk

Update generator and specs

For 4 years we've had logic in our database migrations that required you
to set a constant `DOWNTIME = true` if you required downtime and seek
approval from the VP of Engineering. We have never once used this
process as we've always found a way around the problem using a different
approach.

As such we decided in
https://gitlab.com/gitlab-org/gitlab/-/issues/326495 that we should just
remove this `DOWNTIME` constant and the extra checks here to reduce
noise in our database code review and give less processes for people to
learn.

This MR removes a lot of things and here is a high level summary:

1. Remove DowntimeCheck class and the rake task that invoked and the CI
job that invoked that rake task and any related tests, helper classes
2. Update documentation to make it clearer that downtime is not allowed
and therefore remove the approval process
3. Update a page called `what_requires_downtime` to be called
`avoiding_downtime_in_migrations` since it was already a set of patterns
to avoid downtime and now it's worded more strongly to imply that we can
always get away without downtime
4. Various other docs pages that had examples of migrations that used
the `DOWNTIME` constant
5. Various rubocop specs that had migrations in them which used the
`DOWNTIME` constant

The one thing I did not do is go back and remove `DOWNTIME = false` from
all the existing migrations. In general we should not be updating
migrations once they've run and this would have made this MR change many
thousands of files so it's not worth it.

- since this method is deprecated we shouldn't
mention it in guidance as it can be confusing