This change adds developer documentation on using distributed tracing
using Jaeger.

This reverts commit 676e0a32.
It was removed when we thought we were moving to Looker.

Previously GraphQL field authorization happened like this:

    class ProjectType
      field :my_field, MyFieldType do
        authorize :permission
      end
    end

This change allowed us to authorize like this instead:

    class ProjectType
      field :my_field, MyFieldType, authorize: :permission
    end

A new initializer registers the `authorize` metadata keyword on GraphQL
Schema Objects and Fields, and we can collect this data within the
context of Instrumentation like this:

    field.metadata[:authorize]

The previous functionality of authorize is still being used for
mutations, as the #authorize method here is called at during the code
that executes during the mutation, rather than when a field resolves.

https://gitlab.com/gitlab-org/gitlab-ce/issues/57828

Signed-off-by: NTakuya Noguchi <takninnovationresearch@gmail.com>

Markdown renderers find it easier to determine
where lists start and end when lists are surrounded
by new lines.

For consistency, also ensure entries in the list
are aligned when they span multipls lines.

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

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

Use consistent language (end-to-end instead of integration).

Clarify purpose of `qa/specs/features/` vs. `spec`

For the sake of consistency, removes any extraneous
consecutive blank lines from the doc suite.

This helped me troubleshoot
https://gitlab.com/gitlab-org/gitlab-ee/issues/9727#note_141202527.

Make danger pick reviewers and maintainers at random, for feontend,
backend, database, etc, changes, whenever files belonging to those
teams get changed.

- Add link to Event tracking in FE guides

By setting expectations both the contributor and reviewer have more
certainty on what gets reviewed when, and at what speed changes could be
merged.

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

Start writing some development guidelines in relation to our Kubernetes
integration

Instead of requiring one separate document for every version (which is
created by release managers), we now use a single document for both
Community Edition and Enterprise Edition. This allows developers to add
guidelines right away, instead of release managers having to determine
what to add.

Version specific upgrading instructions are placed in a separate
section. This prevents instructions from lingering around for many
versions should a developer forget to remove them. This also ensures
that all instructions are kept in a single place, instead of being
spread across different documents.

A minor downside is that CE and EE guidelines now live in the same
document, which could cause merge conflicts. Since we are working
towards a single codebase, this should only be an issue until we merge
the codebases together; something we expect to do in the coming months.

This commit also removes all old upgrading instructions, but these can
still be accessed using Git branch specific URLs (included in the
updating README).

This adds a small line to the MR workflow to clarify that new source
installation requirements have to be added when they are introduced,
instead of release managers having to add them.