Don't use TestLicense.destroy! as it triggers License.block_changes? which will block funcionality unintentionally

They are confusing.

Only if the issuable allows multiple assignees the `/reassign` command
should be enabled.

While at it, put all EE-specific Quick Action in a separate file.

Also, port back the original CE specs of QuickActionsServices and put
the differences in a separate EE-only file.

Take over the original CE specs and put the EE-specific specs to a
separate file. The CE spec has `TestLicense.destroy!` to make EE act
like EE.

Simply because it's no longer used.

Only Issue might allow multiple assignees, but only when the
multiple_issue_assignees feature is available. Do this check in Issue
itself, instead of a type-based check in Issuable.

Make sure that EE acts as CE when there is no valid license.

So reactivate the original CE specs and put the licensed EE specs in
separate files.

Using this helper will make it easier in the future to find all
places where the TestLicense is activated or deactivated.

And bring back in sync with CE.

Depending if Multiple Issue Assignees are enabled, make it possible to assign
multiple users to an issue.

Set the assignee to last user in the array if multiple assignees aren't
allowed.

Also, use `parse_params` where possible.

To make it simpler to assign users to an Issuable, make MergeRequest
support the attribute `assignee_ids`.

The /reassign quick command should work even when no multiple assignees are
allowed of there isn't any assignee yet.

For consistency, it will also be backported to CE. The functionality will be the
same as the /assign quick action.

The /reassign slash command only is used in EE, so move it outside the shared
code to avoid merge conflicts.

The list of attributes for the filtered search input was getting long, so use a
helper method to fill that hash.

Also, for multiple issue assignees, a helper is more convenient because it would
allow EE to override the behavior if MIA is supported.

Pass multiple assignee availability boolean to FE and set for use in FilteredSearchTokenKeysIssuesEE

Instead of checking in `SlashCommands::InterpretService` what the issuable the
type of the issuable is, ask the issuable if it is capable to do those thing and
implement it in the issuable itself. The issuable will check if it's possible
and if the licensed feature is available.

This should also make it easier to ever add multiple assignees to MergeRequests.

Depending if Multiple Issue Assignees are enabled, make it possible to assign
multiple users to an issue.

Instead of telling the `FormHelper#issue_assignees_dropdown_options` if there
are multiple assignees enabled, make it figure it out itself.

The implementation for CE will never have multiple
assignees. `EE::FormHelper#issue_assignees_dropdown_options` will have it if the
feature is enabled in the license.

Fix EE conflicts for 'Fix `migration:path` build for "Honor the 'Remember me' parameter for OAuth-based login"'

See merge request !2355

Update alpha database documentation to reflect change in attribute

See merge request !2252

Improve state management for deploy boards with realtime data

Closes #2677

See merge request !2311

EE: Add foreign keys to various tables that point to the "projects" table

See merge request !2223

Add overview and use cases for db load balancing docs

See merge request !2342

This cop has been renamed to ActiveRecordSerialize to match the way
"ActiveRecord" is usually written.

These are specific to EE and a whole bunch of these can be fixed by just
removing the `dependent:` option since we now have more foreign keys in
place.

This adds various missing foreign keys (with cascading deletes) that
either point directly or indirectly to the "projects" table.

These IDs point to non-existing rows, causing the foreign key
constraints to fail.

This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).

This removes the need for relying on Rails' "dependent" option for data
removal, which is _incredibly_ slow (even when using :delete_all) when
deleting large amounts of data. This also ensures data consistency is
enforced on DB level and not on application level (something Rails is
really bad at).

This commit also includes various migrations to add foreign keys to
tables that eventually point to "projects" to ensure no rows get
orphaned upon removing a project.

Add use cases for issues-related EE features

Closes #2810

See merge request !2330