Resolution issues with valid permissions in NuGet virtual repositories

Unable to resolve packages from virtual repositories when the requesting client doesn’t have any permissions to a repository in the virtual aggregation which is higher in the aggregation order than the repository from which you expect the package to be resolved from, OR there is a permission target with an include pattern configured on the higher-ordered repository.

Steps to reproduce (docker)

1. Create a docker local repository (docker-local)
2. Create a smart remote docker repository (docker-smartremote) to a local docker repository in a distant Artifactory instance. Supply the relevant admin credentials for the target Artifactory instance (if it needs auth).
3. Create a docker remote repository (docker-remote) default to docker hub is fine
4. Create a virtual (docker-virtual) which aggregates in order 1)docker-local 2)docker-smartremote 3)docker-remote
5. Create a permission target for anonymous & all authenticated users to be able to pull from docker-local and docker-remote
6. DO NOT create a permission target for docker-smartremote OR create a permission target with an include pattern (anything but ** or */ catch all) for docker-smartremote
7. As an anonymous/unauthenticated user (or anything except an admin user), request an image from docker-virtual that you know exists at docker-remote, e.g. docker pull docker-virtual.artifactory.domain.local/logstash:6.8.1

Expected Behaviour

1. Client is able to pull the image via the docker virtual repository – the image is cached in docker-remote-cache

Observed Behaviour

1. Client is NOT able to pull the image via the docker virtual repository – the client receives the following error: “unauthorized: The client does not have permission for manifest: Download request for repo:path 'docker-smartremote-cache:logstash/6.8.1/list.manifest.json' is forbidden for user 'anonymous'.”
2. The client IS able to pull the image directly from docker-remote (expected > due to perm target created in reproduction step 5)
3. The same issue is observed if there is a permission target for docker-smartremote but it has an includes pattern which isn’t a catch all (i.e. not ** or */ - in our case “gr/**” needs to be configured as the includes pattern for the smart remote repositories).
4. This cannot be reproduced in Artifactory 6.11.3 

The same issue could be reproduced for a NuGet full-mesh.