Forward Jira uninstall events to self-managed

What does this MR do?

This is a part of the &5650 (closed) epic to make the GitLab for Jira app available for self-managed using gitlab.com as a proxy.

In this part we want to enable gitlab.com to forward event hooks to a self-managed instance.

Jira can send lifecycle events to installed apps. We currently use installed and uninstalled.

When receiving an installed event:

• If the request does not contain a valid JWT token, this means, there is no matching installation, and we will create a new one.
• If the JWT is valid. Meaning we already have an installation we just respond with :ok without any further action.

When receiving an uninstalled event:

• We delete the installation

Now with the ability to set an instance_url, the JiraConnectInstallation will serve as a proxy for another instance, and we need to forward the events to the instance. installed event don't need to be forwarded because for the initial event with a new installation, instance_url can not be set and for existing installations, we don't do anything except from responding with :ok. For uninstalled event we would need to forward the request and delete the installation afterwards.

I have not added a changelog entry because this is not a user facing change. There currently is no UI for setting instance_url

How to test

I made a 📺 video showing how the changes can be tested using Gitpod.

To test this, two publicly available GitLab instances are needed:

1. Start two Gitpods, one on master (I'll call this one self-managed) and one on 325282-forward-proxied-jira-connect-events (I'll call this one dotcom)
2. Make sure the Gitpods are up and running and app descriptor on dotcom can be accessed under https://3000-GITPOD_ADDRESS.gitpod.io/-/jira_connect/app_descriptor.json
3. Go to your Jira/Atlassian account and navigate to Apps -> Manage your apps
4. Open Settings and enable development mode
5. Click Upload App
6. Enter the app descriptor URL (https://3000-GITPOD_ADDRESS.gitpod.io/-/jira_connect/app_descriptor.json) and click Upload
7. On the dotcom Gitpod open the rails console with bundle exec rails c
8. Run JiraConnectInstallation.count. The result should be 1 meaning the installation was successfully created
9. Assign a variable to the URL of the self-managed Gitpod `instance_url = 'https://3000-SELF_MANAGED_GITPOD_ADDRESS.gitpod.io' (without the trailing slash!)
10. Set up the installation by running this snippet on the dotcom Gitpod rails console
11. Now open a console on the self-managed Gitpod by running bundle exec rails c
12. Verify that the installation got created there too with JiraConnectInstallation.count. The result should be 1 meaning the installation was successfully created
13. Go back to the Jira and click Uninstall
14. On both Gitpods the result of JiraConnectInstallation.count should be 0 now meaning both installations has been successfully removed.

Does this MR meet the acceptance criteria?

Conformity

• I have included a changelog entry, or it's not needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• [-] I have tested this MR in all supported browsers, or it's not needed.
• [-] I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Related to #325282 (closed)