Make sure the background migration is finalized before last required
stop (min GitLab schema version).

Fix RSpec/BeNil rubocop offenses

- lean into the existing API/matcher
- update docs

We've switched to Ruby 3.2+ so this code works without `keyword_init:
true`:

  X = Struct.new(:a)
  X.new(1)    # => #<struct X a=1>
  X.new(a: 1) # => #<struct X a=1>

This check is no longer necessary.

Partially reverts https://gitlab.com/gitlab-org/gitlab/-/merge_requests/164777

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

This commit patches `Struct.new` in specs when `keyword_init` is missing
and a Hash passed.

Reason: Since Ruby 3.2 `Struct` supports kwargs by default so
`keyword_init: true` is no longer required.  We are running Ruby 3.2 in
MRs and Ruby 3.1 on master so occasionally master is broken due to this
incompatibility.

This slows down creation of Struct objects in specs by factor 3.

This reverts merge request !164777

This commit patches `Struct.new` in specs when `keyword_init` is missing
and a Hash passed.

Reason: Since Ruby 3.2 `Struct` supports kwargs by default so
`keyword_init: true` is no longer required.  We are running Ruby 3.2 in
MRs and Ruby 3.1 on master so occasionally master is broken due to this
incompatibility.

This slows down creation of Struct objects in specs by factor 3.

According to https://gitlab.com/gitlab-com/www-gitlab-com/-/commit/6b12a117df56527328d99a7eb57e5cd18d439d06

This new PR assigns auto populated columns:
https://github.com/rails/rails/pull/48241

However, a column is identified as auto-populated if it contains
default value with nextval function.

The id column of p_ci_builds table is auto-populated via a trigger
and it's not identified as an auto-populated column by Rails.

Let's explicitly return ['id'] in a function that expects a list
of auto-populated columns

Fix additional properties in the matcher

Use wait_for_requests instead of wait_for_all_requests because
a user only expects to wait for JS requests and not rack requests

Testing for internal events currently uses a single shared example.
This has some limitations, however, in handling a variety of different
scenarios.

This adds two custom matchers:
:trigger_internal_events
:increment_usage_metrics

These matchers can be used to compose examples that directly reflect
the expected outcomes of for internal events.

When the finalized_by key is present in the BBM dictionary file,
the migration version should be cast as an integer, otherwise
ActiveRecord will fail to find the target version, and it will
throw an error.

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/151467#note_1887895592

Changelog: fixed

Changelog: other

This speeds up testing `ee/spec/models/factories_spec.rb` in a
predictive or "fail-fast" CI job. The full spec is still run after
approval, merge, and in scheduled pipelines.

Currently it's not possible to use `:published_event` and
`:not_publish_event` together as both matchers are stubbing the
`Gitlab::EventStore#publish` method, so only the first matcher will save
a list of the _published_ events.

To fix that, now we're using `RSpec::PublishedGitlabEventStoreEvents`
to centralized all the events published within an example. This will
enable us to match by multiple events or compose `:published_event` and
`:not_publish_event` in the same spec.

Changelog: fixed

This reverts commit a7f569b2.

This reverts merge request !144300

This reverts merge request !144224

This reverts merge request !141213

Changelog: other

- move away from instance specific checks.
- resolve ee vs foss separation issues.
- resolve some rubocop exceptions.
- see https://gitlab.com/gitlab-org/gitlab/-/issues/350222 for more info

So that we can test flows that result in multiple calls to
Gitlab::Saas.feature_available?, we now stub the default value for all
known SaaS features to false

- spec/services/**
- spec/sidkiq*/**
- spec/support/**

- better conformity to current hash styles

- declaritive way to not be saas w/o stubbing the method
- goes hand in hand with the negative of :saas