Add maven virtual registry crud endpoints for cached response

🔭 Context

With Maven virtual registry MVC (single upstream and... (&14137), we're starting the work on Virtual Registries. Virtual Registries is a feature that could be described as the evolution of the dependency proxy idea: having the GitLab instance play man in the middle between clients and artifacts registries. Artifacts can be any kind, but we're going to focus on packages and container images, starting with Maven packages specifically.

The maven virtual registry mainly consists of 3 entities (models that are backed up with database tables): Registries, Upstreams, and CachedResponses. For each entity, we need to support crud APIs, so users can list/create/update/delete those entities in their groups.

In this MR, we are adding two needed crud endpoints for the 3rd entity: CachedResponses. Crud endpoints for Registries & Upstreams were introduced in !161615 (merged) & !162019 (merged) respectively.

What does this MR do and why?

Adding the following endpoints and their covering specs:

Cached responses

Route	Notes
GET /api/v4/virtual_registries/packages/maven/registries/:registry_id/upstreams/:upstream_id/cached_responses	We should support a fuzzy search on the relative_path attribute.
DELETE /api/v4/virtual_registries/packages/maven/registries/:registry_id/upstreams/:upstream_id/cached_responses/:cached_response_id	cached_response_id can be the encoded relative_path as it is unique within upstream id, and we don't really need a primary key on cached responses.

The GET request has the following attributes:

• search. Search term to match the relative_path field of cached responses. Simple fuzzy search supported such as *foo*bar.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

1. Enable the feature flag : Feature.enable(:virtual_registry_maven).
2. Make sure you have the dependency proxy enabled in your GDK, or simply comment out this line for easier testing.
3. Have a PAT and a root group (any visibility) ready.
4. In rails console:

   # create a registry
   r = ::VirtualRegistries::Packages::Maven::Registry.create!(group: <root_group>)
   
   # create an upstream
   u = ::VirtualRegistries::Packages::Maven::Upstream.create!(group: <root_group>, url: "http://sandbox.test")
   
   # create a registry_upstream
   VirtualRegistries::Packages::Maven::RegistryUpstream.create!(group: <root_group>, registry: r, upstream: u)
   
   # create a couple of cached_responses
   cr1 = ::VirtualRegistries::Packages::Maven::CachedResponse.create!(group: <root_group>, upstream: u, relative_path: '/test/foo', size: 10, file: Tempfile.new('foo'))
   cr1 = ::VirtualRegistries::Packages::Maven::CachedResponse.create!(group: <root_group>, upstream: u, relative_path: '/test/bar', size: 15, file: Tempfile.new('bar'))

5. List the available cached_responses of the upstream using GET /api/v4/virtual_registries/packages/maven/registries/:registry_id/upstreams/:upstream_id/cached_responses endpoint:

   curl -i http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries/<r.id>/upstreams/<u.id>/cached_responses

6. Search for a specific cached_response by passing the search query param:

   curl -i http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries/<r.id>/upstreams/<u.id>/cached_responses?search=foo

7. Delete a cached_response using DELETE /api/v4/virtual_registries/packages/maven/registries/:registry_id/upstreams/:upstream_id/cached_responses/:cached_response_id endpoint:

   curl -i -X DELETE http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries/<r.id>/upstreams/<u.id>/cached_responses/<cached_response_base64_encoded_relative_path>

Related to #467979 (closed)