Add error handling in the container registry delete tags service

😎 Context

When container registry cleanup policies are executed, the background worker will build a list of container registry tags to delete and use different services to delete them. I will not detail all the code flow across the different service but just know that the delete tag service is the very last service that actually executes the deletes.

Now, container registry tags are not the usual database persisted objects. They live in the container registry exclusively. As such, to delete a tag, a DELETE request has to be made on the container registry API.

From the rails backend point of view, we have a network interaction with the "outside" world (even though it's still within GitLab backends). Having a network interaction means that bad things could happen 💥.

These errors being not handled, they bubble up and they disrupt the background execution of cleanup policies: the execution has states attached to it so that the backend can monitor what is happening. One of these states is unfinished meaning that the execution had to stop. These network errors should result in putting the execution in the unfinished state.

See #280545 (closed) for more details.

🤔 What does this MR do?

• The delete tag service will now return a service error response upon any error, including network errors.
  • The error class name will be returned
• There is nothing to do to put the cleanup policy execution in the unfinished state. It's already handled by a service that upon receiving a service error response will put the execution in the proper state.

🖼 Screenshots (strongly suggested)

n / a

🔩 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

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