Add handlers for Jira connect error responses

What does this MR do?

This adds error handlers for the error formats described at:

• https://developer.atlassian.com/cloud/jira/software/rest/api-group-feature-flags/#api-featureflags-0-1-bulk-post
• https://developer.atlassian.com/cloud/jira/software/rest/api-group-deployments/#api-deployments-0-1-bulk-post
• https://developer.atlassian.com/cloud/jira/software/rest/api-group-builds/#api-builds-0-1-bulk-post

Each of these needs slightly different handling.

QA instructions

This can be QA'ed manually using a gitpod instance.

• Enable the :jira_sync_deployments, :jira_sync_builds and :jira_sync_feature_flags feature flags in the Rails console
• Install or update your JiraConnect installation (see https://gitlab.com/gitlab-org/gitlab/blob/master/doc/development/integrations/jira_connect.md)
• Ensure that you have a runner and working pipelines in your local development environment (https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/runner.md)
• Set up a suitable pipeline with a deploy stage (eg. https://docs.gitlab.com/ee/ci/environments/#defining-environments). Note - your deployment must happen on merge request branches, so that we can associate it with Jira issue keys. Create one or more MR's with references (in branch names or MR title) to different Jira issues. The deployment must also have an environment name (I recommend 'staging', but others are fine).
• Push a change that results in a pipeline and a successful deployment (see below for a suitable build script)
• Create a feature flag naming a Jira issue key in its description.
• Once you have a pipeline, a deployment and a feature flag, you can do the console steps below:

Console steps:

d = Deployment.last
p = d.project
ff = Operation::FeatureFlag.last
pl = Ci::Pipeline.last

s = JiraConnect::SyncService.new(p)
s.execute(feature_flags: [ff], pipelines: [pl], deployments: [d])

This should not fail.

Build Script

I use the following build script with a shell based runner:

before_script:
  - echo "Before script section"
  - echo "For example you might run an update here or install a build dependency"
  - echo "Or perhaps you might print out some debugging details"

after_script:
  - echo "After script section"
  - echo "For example you might do some cleanup here"

build1:
  stage: build
  script:
    - echo "Do your build here"

test1:
  stage: test
  script:
    - echo "Do a test here"
    - echo "For example run a test suite"

test2:
  stage: test
  script:
    - echo "Do another parallel test here"
    - echo "For example run a lint test"

deploy1:
  stage: deploy
  environment:
    name: staging
  script:
    - echo "Deployed"

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability 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
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

It is difficult to test the error behaviour here, but we do need to watch the Sentry reports.

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

Related to #298733 (closed)