Add support for querying epics with GraphQL

What does this MR do?

Allows one to query for epics using a Group GraphQL query.

Example

{
  group(fullPath: "h5bp") {
    id
    path
    fullPath
    epic(iid: 1) {
      id
      iid
      title
      path
      userPermissions {
        adminEpic
        createEpic
      }
      children {
        edges {
          node {
            id
            iid
            title
            state
            path
            reference(full: true)
            relationPath
            createdAt
            closedAt
            hasChildren
            hasIssues
            userPermissions {
              adminEpic
              createEpic
            }
            group {
              fullPath
            }
          }
        }
      }
      issues {
        edges {
          node {
            iid
            title
            closedAt
            state
            createdAt
            confidential
            webUrl
            dueDate
            weight
            path
            reference
            relationPath
            assignees {
              edges {
                node {
                  webUrl
                  name
                  username
                  avatarUrl
                }
              }
            }
            milestone {
              title
              startDate
              dueDate
            }
          }
        }
      }
    }
  }
}

This MR requires (and is based on) https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13246. It has been extracted from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10999

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Performance and testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Closes #10795 (closed)

doc/ci/multi_project_pipelines.md

@@ -134,6 +134,34 @@ staging:
 The `ENVIRONMENT` variable will be passed to every job defined in a downstream
 pipeline. It will be available as an environment variable when GitLab Runner picks a job.
 
+In the following configuration, the `MY_VARIABLE` variable will be passed
+downstream, because jobs inherit variables declared in top-level `variables`:
+
+```yaml
+variables:
+  MY_VARIABLE: my-value
+
+my-pipeline:
+  variables:
+    ENVIRONMENT: something
+  trigger: my/project
+```
+
+You might want to pass some information about the upstream pipeline using, for
+example, predefined variables. In order to do that, you can use interpolation
+to pass any variable. For example:
+
+```yaml
+my-pipeline:
+  variables:
+    UPSTREAM_BRANCH: $CI_COMMIT_REF_NAME
+  trigger: my/project
+```
+
+In this scenario, the `UPSTREAM_BRANCH` variable with a value related to the
+upstream pipeline will be passed to a `downstream` job, and will be available
+within the context of all downstream builds.
+
 ### Limitations
 
 Because bridge jobs are a little different to regular jobs, it is not