The SanitizationFilter was running before the WikiFilter. Since
WikiFilter can modify links, we could see links that _should_ be stopped
by SanatizationFilter being rendered on the page. I (kerrizor) had
previously addressed the bug in: https://gitlab.com/gitlab-org/gitlab-ee/commit/7bc971915bbeadb950bb0e1f13510bf3038229a4
However, an additional exploit was discovered after that was merged.
Working through the issue, we couldn't simply shuffle the order of
filters, due to some implicit assumptions about the order of filters, so
instead we've extracted the logic that sanitizes a Nokogiri-generated
Node object, and applied it to the WikiLinkFilter as well.

On moving filters around:
Once we start moving around filters, we get cascading failures; fix one,
another one crops up. Many of the existing filters in the WikiPipeline
chain seem to assume that other filters have already done their work,
and thus operate on a "transform anything that's left" basis;
WikiFilter, for instance, assumes any link it finds in the markdown
should be prepended with the wiki_base_path.. but if it does that, it
also turns `href="@user"` into `href="/path/to/wiki/@user"`, which the
UserReferenceFilter doesn't see as a user reference it needs to
transform into a user profile link. This is true for all the reference
filters in the WikiPipeline.

Fabio Pitino authored 5 years ago and Marin Jankovski committed 5 years ago

It keeps track of the memory being used when loading the YAML file
as well as the depth of nesting.
Track exception when YAML is too big

Signed-off-by: Rémy Coutable <remy@rymai.me>

Override now cares about parents method arity: if parents arity
doesn't match raises an error.

Enables frozen string for the following:

* lib/gitlab/patch/**/*.rb
* lib/gitlab/popen/**/*.rb
* lib/gitlab/profiler/**/*.rb
* lib/gitlab/project_authorizations/**/*.rb
* lib/gitlab/prometheus/**/*.rb
* lib/gitlab/query_limiting/**/*.rb
* lib/gitlab/quick_actions/**/*.rb
* lib/gitlab/redis/**/*.rb
* lib/gitlab/request_profiler/**/*.rb
* lib/gitlab/search/**/*.rb
* lib/gitlab/sherlock/**/*.rb
* lib/gitlab/sidekiq_middleware/**/*.rb
* lib/gitlab/slash_commands/**/*.rb
* lib/gitlab/sql/**/*.rb
* lib/gitlab/template/**/*.rb
* lib/gitlab/testing/**/*.rb
* lib/gitlab/utils/**/*.rb
* lib/gitlab/webpack/**/*.rb

Partially addresses gitlab-org/gitlab-ce#47424.

We should never be sloppy!

Since extending a class means including on the singleton class of the
class, this should now complain this:

``` ruby
module M
  extend Gitlab::Utils::Override

  override :f
  def f
    super.succ
  end
end

class C
  extend M

  def self.f
    0
  end
end
```

It should complain because `C.f` wasn't calling `M#f`.
This should pass verification:

``` ruby
module M
  extend Gitlab::Utils::Override

  override :f
  def f
    super.succ
  end
end

class B
  def self.f
    0
  end
end

class C < B
  extend M
end
```

Because `C.f` would now call `M#f`, and `M#f` does override something.

The Gitaly CommitService is being hammered by n + 1 calls, mostly when
finding commits. This leads to this gRPC being turned of on production:
https://gitlab.com/gitlab-org/gitaly/issues/514#note_48991378

Hunting down where it came from, most of them were due to
MergeRequest#show. To prove this, I set a script to request the
MergeRequest#show page 50 times. The GDK was being scraped by
Prometheus, where we have metrics on controller#action and their Gitaly
calls performed. On both occations I've restarted the full GDK so all
caches had to be rebuild.

Current master, 806a68a8, needed 435 requests
After this commit, 154 requests

Since it can technically merge any hash with objects that respond to `==`