Introduction of an additional parameter for pull-through caching to enable an initial pull of a container image without user authentication

Is your feature request related to a problem? Please describe.
I've created a "Pull-Through Caching" for a remote container registry according to this HOWTO: https://pulpproject.org/pulp_container/docs/admin/guides/pull-through-caching/
Currently, the default behavior for the first pull of a certain image into the cache is that the user needs to be authenticated, see https://github.com/pulp/pulp_container/blob/main/pulp_container/app/registry_api.py#L320
If not, the user get's a message "Error response from daemon: pull access denied for ...".
The first pull implicitely creates the concerned Pulp objects of type repository and distribution (the latter with the attribute "private": false) for each remote container repository.
For the second and any further pulls, there is no need to be authenticated.

Describe the solution you'd like
It would be great, if an additional parameter/option can be introduced for creating a new "Container Pull-Through Caching Distribution" via /api/v3/distributions/container/pull-through/.
This parameter/option could e.g. be named private and the value set could be true and false.
If the value is true, which is the default, than the behaviour is like it is now (or maybe should even be changed, so that for every pull, user authentication is needed, so that it behaves comparable to a normal "Container Distribution" via /api/v3/distributions/container/container/).
If the value is false, than the behaviour is like that for every pull, no user authentication is needed.

Describe alternatives you've considered
Change the default behaviour of "Pull-Through Caching", so that a pull of a container image never needs user authentication.

Start in pulp_container/app/registry_api.py around line 320 and inspect the pull-through distribution endpoint at /api/v3/distributions/container/pull-through/. Trace how the private attribute is set and how authentication is checked during the first and subsequent pulls. Done means the endpoint accepts the proposed option and the selected authentication behavior is applied consistently.