Retry proxied JiraConnection installation deletion if the remote server is not reachable

The following discussion from !62144 (merged) should be addressed:

• @toupeira started a discussion: (+2 comments)

  thought: I'm wondering why we're always destroying the installation, even if the self-managed instance didn't succeed.

  I guess it makes sense when the self-managed instance is permanently gone, so we can still clean up the record on gitlab.com. When self-managed has a temporary problem it might make sense to try again (which I believe will already happen currently, since this is a worker and we don't rescue the exception), but at that point the installation won't exist anymore and the worker will just exit.

  Also, this is happening in the background, so the app entry in Jira is already gone and the user can't re-trigger the uninstall event manually. And as Andy mentioned in the video Jira actually ignores errors from the uninstall endpoint, so I guess we can't be smarter about our response either. 🤔

  I see two strategies:

  1. Rescue errors and don't try again, which wouldn't work anyway as the installation is already destroyed on the next attempt.
     • I think we'd have to rescue Gitlab::HTTP::HTTP_ERRORS, and also check for success? on the Gitlab::HTTP.post call.
  2. Only destroy the installation if no errors happened, and let the worker retry.
     • This means the installation would stick around on gitlab.com if the self-managed instance isn't reachable anymore.
     • Maybe we have a way to check if this is the last retry for the worker? This sounds brittle too though.

  So I think for simplicity we should go with option 1, but maybe I'm misunderstanding something and the current code is fine too?