Add GraphQL mutation for container expiration policy

What does this MR do?

This MR is a follow up of !32100 (merged) for issue #196784 (closed).

!32100 (merged) added the GraphQL type and the query part.

This MR adds the mutation part for container expiration policy.

Design choices

• Notice that a project has_one container expiration policy. As such, the ContainerExpirationPolicy doesn't have a dedicated primary key (see https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/structure.sql#L1972-1984). As such, the project_id is used as primary key in this table.
• A container expiration policy is created each time a project is created. (see https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/project.rb#L101)
• So we have two cases:
  1. projects that have a container expiration policy.
  2. projects that don't have a container expiration policy. (they existed before container expiration policy were added)
• Note that (1.) will prevail (as in we will have way more (1.) than (2.)) as time goes by.
• We don't want to have a complex mutation query to handle both cases.
• We made the design choice that the service used by the graphQL mutation will handle both:
  • On existing container expiration policies, updates will be issued.
  • On non existing container expiration policies, creations will be issued.
• As such, this MR adds a single mutation: UpdateContainerExpirationPolicy. The id used for the mutation is simply the project_path.
• In short, the graphQL mutation is: "here is the container expiration policy I want to set and I don't care if the container expiration policy exists or not. Deal with it, that's your job, Mr. Backend."
• The Project factories have been updated to be able to create Projects without a container expiration policy.
• The examples at the service level have been shared to be re-used at the GraphQL mutation level and the GraphQL request level.
• This is a ~backstage MR but since we're adding a new part to the GraphQL, we think that it still warrants a changelog entry.

Screenshots

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