[Geo] Minor fix for rake geo:status task

See merge request gitlab-org/gitlab-ee!5480

Geo: Refactor FileDownloadDispatchWorker JobFinders and FileRegistryFinders

Closes #5601

See merge request gitlab-org/gitlab-ee!5331

Merge branch 'ee-46049-import-export-import-is-broken-due-to-the-addition-of-a-ci-table' into 'master'

EE Port for: "Resolve "Import/Export (import) is broken due to the addition of a CI table""

See merge request gitlab-org/gitlab-ee!5577

[EE] Enforce application wide terms

See merge request gitlab-org/gitlab-ee!5529

Adds update guide for 10.8 from CE to EE

See merge request gitlab-org/gitlab-ee!5548

Add Group level SAML callback for GitLab.com SSO

Closes #4514

See merge request gitlab-org/gitlab-ee!5575

We need to catch exception when even_log is not found

[EE] Enforce application wide terms

See merge request gitlab-org/gitlab-ee!5529

Make empty state copy aware of applied filters in Epics list and Roadmap view

See merge request gitlab-org/gitlab-ee!5465

Resolve "ee-specific-lines-check should not check against CE master"

Closes #5869

See merge request gitlab-org/gitlab-ee!5564

See https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/5572

Merge branch '4957-projectsyncworker-should-skip-projects-that-have-a-broken-gitaly-shard' into 'master'

Resolve "ProjectSyncWorker should skip projects that have a broken Gitaly shard"

Closes #4957

See merge request gitlab-org/gitlab-ee!5514

Merge branch '4957-projectsyncworker-should-skip-projects-that-have-a-broken-gitaly-shard-3' into 'master'

Shard name vs. Shard updates, general tech debt cleanup

Closes #4957

See merge request gitlab-org/gitlab-ee!5555

If CE master is ahead of EE master, and the CE branch
was forked from CE master, then the CE branch would
contain a lot of changes which aren't presented in EE master,
therefore they're not presented in EE branch, either.

In this case, we need to remove the commits from CE master
which aren't merged into EE yet. So we want to rebase CE branch
onto CE/EE merge base, with ce_fetch_base and ce_fetch_head,
where ce_fetch_base is the merge base of CE master and CE branch,
and ce_fetch_head is the original HEAD of CE branch.

This should make sure there's no extra commits involved.

The only way it could fail would be conflicts during rebase,
which ideally should not happen at all. This doesn't mean
it's impossible to happen, but given the reason we make the CE branch,
it should only contain minimum changes from EE to CE, which shouldn't
conflict.

Let's try this and see and investigate if conflicts happen.

Since we're not showing system footer and header on these pages, we
should not add margin when they are enabled

`InternalRedirect` prevents Open redirect issues by only allowing
redirection to paths on the same host.

It cleans up any unwanted strings from the path that could point to
another host (fe. //about.gitlab.com/hello). While preserving the
querystring and fragment of the uri.

It is already used by:

- `TermsController`
- `ContinueParams`
  - `ImportsController`
  - `ForksController`
- `SessionsController`: Only for verifying the host in CE. EE allows
   redirecting to a different instance using Geo.

This enforces the terms in the web application. These cases are
specced:

- Logging in: When terms are enforced, and a user logs in that has not
  accepted the terms, they are presented with the screen. They get
  directed to their customized root path afterwards.
- Signing up: After signing up, the first screen the user is presented
  with the screen to accept the terms. After they accept they are
  directed to the dashboard.
- While a session is active:
  - For a GET: The user will be directed to the terms page first,
    after they accept the terms, they will be directed to the page
    they were going to
  - For any other request: They are directed to the terms, after they
    accept the terms, they are directed back to the page they came
    from to retry the request. Any information entered would be
    persisted in localstorage and available on the page.

When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.

This will act as a cache, otherwise we would need to load the
`term_agreements` for a user on each request.

Using this field the result we're interested in is loaded when the
current user is loaded, without causing an extra query.

When terms are present, they can be viewed on `/-/users/terms`.

We will reuse the the dropdown, but exclude some menu items based on
permissions.

So moving the menu to a partial, and adding checks for each menu item here.

This allows admins to define terms in the application settings.

Every time the terms are adjusted, a new version is stored and becomes
the 'active' version. This allows tracking which specific version was
accepted by a user.

That way we can link a users acceptance of terms directly to a terms record.