This change adds support for GitLab CI integration. This works similarly to how many of our integrations do, where the integration can trigger a new pipeline. Because of how pipeline configurations work, we can't completely replace the configuration when starting the pipeline. We therefore send necessary information as variables, and it's up to the user to add what they need to their .gitlab-ci.yml file. Documentation for how to do all of that will be in a separate change for the Review Board manual. This does have one additional feature over other CI integrations, where the individual job state can be posted as a review. Based on work by André Klitzing at /r/14211. There are a few differences in functionality from that change: - Rather than asking the user to put the API token into the GitLab WebHook configuration's secret field, we allow (optionally) setting a specific secret key for both the webhook and the integration. - Instead of posting job results in a review and then deleting it whenever there's an update, those results are put into a general comment (without an issue) and then the text of that comment gets updated. We theoretically like to treat comment text as immutable once published, but in this case I think it's fine. - I've gotten rid of the `gitlab_old_pipeline` setting entirely. In the case that pipelines are getting rerun, I think it makes sense to always get those updates on Review Board. In the case where a child pipeline is sending updates, I've just added notes in the documentation that triggers really should set `strategy: depend` so that parent pipelines will wait for their children to complete. - I've added a new dependency on `pydantic` for parsing the WebHook payload structure. - Added unit tests for everything. - Various things have been renamed and cleaned up to match our style. Testing Done: - Created a variety of GitLab CI setups, including simple jobs and parent/child pipelines. Verified that pipelines were triggered successfully and results posted back. - Ran unit tests.