Fix GitLab project import when a user has access only to their default namespace

## What does this MR do?

It fixes a bug when a namespace ID was not passed to `/import/gitlab_project/new` page. It occurred when a user have no choice of the namespace, so we did not render the input for namespace ID. This MR introduces a hidden input for the described case.

## Does this MR meet the acceptance criteria?

- Tests
  - [x] Added for this feature/bug
  - [x] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

Fixes #23507

See merge request !6995

Fix a 500 error viewing an MR with a deleted source project

## What does this MR do?

Allows merged MRs to be shown without any 500 errors if the source project is removed

## Are there points in the code the reviewer needs to double check?

https://gitlab.com/gitlab-org/gitlab-ce/commit/31c37c6c38258684fc92e0d91119c33872e39034 fixed this for closed MRs only. I had trouble understanding the introduced helper and logic, so reverted it and keyed everything on the existence of the source project or branch directly.

commits.json returns a 500 error for a closed or merged MR; the approach taken in the above MR was to hide the commits... tab, so I've run with that.

For merged MRs, the commits (but not the pipeline data) are in the target project, so we *could* do better, but it's a fairly nasty intervention to make it happen.

## Why was this MR needed?

Viewing merged MRs should work even if the fork they came from has been deleted or unlinked.

## Screenshots (if relevant)

![Screen_Shot_2016-10-19_at_17.56.37](/uploads/1aeadd5147b9a4ad29b946b1c7ea52cb/Screen_Shot_2016-10-19_at_17.56.37.png)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG.md) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
  - [x] Added for this feature/bug
  - [ ] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

Closes #23341

See merge request !6991

Refactor the spec file:
- remove hardcoded record IDs
- avoid top-level let if not used in all scenarios
- prefer expect { ... }.to change { ... }.from(0).to(1) over checking
that there are no records at the beginning of the test

At the moment we cannot see weather a user left a project due to their
membership expiring of if they themselves opted to leave the project.
This adds a new event type that allows us to make this differentiation.
Note that is not really feasable to go back and reliably fix up the
previous events. As a result the events for previous expire removals
will remain the same however events of this nature going forward will be
correctly represented.

Add group level labels

## What does this MR do?

Add group level labels.

## Are there points in the code the reviewer needs to double check?

* `LabelsFinder`
* `Gitlab::Gfm::ReferenceRewriter`
* `Banzai::Filter::LabelReferenceFilter`

## Why was this MR needed?

We'll be adding more feature that allow you to do cross-project management of issues.

## Screenshots (if relevant)

* Group Labels
    ![Group Labels](/uploads/2244c06ad68eae4fb246fb4c81bf8060/2.png)

* Project Labels
    ![Project Labels](/uploads/c5839516d2282b51f7418d9dadbeceb4/1.png)

* Expanded references for group labels when moving issue to another project
    ![Expanded references for group labels when moving issue to another project](/uploads/0c9ab248a8420d4978d59349ae3d42e5/3.png)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
  - [x] Added for this feature/bug
  - [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

#19997

See merge request !6425

`Reset filters` link should only be visible when filters are active

## Why was this MR needed?

`Reset filters` link is always visible.

Closes #22457

See merge request !6497

Fixed all related specs and also changed the logic to handle edge cases. This includes exporting and exporting of group labels, which will get associated with the new group (if any) or they will become normal project labels otherwise.

Found other issues to do with not being able to import all labels at once in the beginning of the JSON - code was much simpler when we import all labels and milestones associated to a project first, then the associations will find the already created labels instead of creating them from the associations themselves.