Include coverage reports from child pipeline

What does this MR do and why?

Include coverage reports from child pipelines when creating pipeline coverage report.

Part of #363301 (closed).

Screenshots or screen recordings

In this sample MR, alberts-gitlab/test-ruby-cobertura!2, there is a parent and child pipeline set up to generate coverage. The parent pipeline generates coverage for demo.rb. The child pipeline generates coverage for demo_child.rb.

Before - coverage from child pipeline is not included:

After - coverage from child pipeline is included:

Example project and MR: alberts-gitlab/test-ruby-cobertura!2

How to set up and validate locally

1. Clone project https://gitlab.com/alberts-gitlab/test-ruby-cobertura locally
2. Pull branch https://gitlab.com/alberts-gitlab/test-ruby-cobertura/-/tree/test-coverage-child-pipeline containing CI and test changes to generate coverage from child pipeline.
3. Create MR in GDK and wait for pipeline to succeed.
4. Verify that the demo_child.rb coverage generated in the child pipeline is not shown in the MR diff.
5. Enable feature flag ci_child_pipeline_coverage_reports.

   Feature.enable(:ci_child_pipeline_coverage_reports)

6. Run a new pipeline on the branch and wait for it to succeed.
7. Verify that the demo_child.rb coverage is now shown in the MR diff.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

doc/development/application_limits.md

@@ -189,3 +189,23 @@ the middleware level, this can be used at the controller or API level.
 
 See the `CheckRateLimit` concern for use in controllers. In other parts of the code
 the `Gitlab::ApplicationRateLimiter` module can be called directly.
+
+## Next rate limiting architecture
+
+In May 2022 we've started working on the next iteration of our application
+limits framework using a forward looking rate limiting architecture.
+
+We are working on defining new requirements and designing the next
+architecture, so if you need new functionalities to add new limits, instead of
+building them right now, consider contributing to the
+[Rate Limiting Architecture Working Group](https://about.gitlab.com/company/team/structure/working-groups/rate-limit-architecture/)
+
+Examples of what features we might want to build into the next iteration of
+rate limiting architecture:
+
+1. Making it possible to define and override limits per namespace / per plan.
+1. Automatically generating documentation about what limits are implemented and
+   what the defaults are.
+1. Defining limits in a single place that is easy to find an explore.
+1. Soft and hard limits, with support for notifying users when a limit is
+   approaching.