cinder image_upload_use_internal_tenant conflicts with image_upload_use_cinder_backend

[李亚冲]

Hi, I find a confict bug in the cinder, When we use image_upload_use_internal_tenant and image_upload_use_cinder_backend at the same time, there will be conflicts.

ok, the code in the cinder/volume/manager.py, function _clone_image_volume_and_add_location,
The following code in this function, `image_volume_context=ctx`, if use image_upload_use_internal_tenant config, it will be overwrite the ctx. (in python language, that's a pointer)

```
 def _clone_image_volume_and_add_location(self, ctx, volume, image_service,
                                             image_meta) -> bool:
        # it will be override became same pointer
        image_volume_context = ctx
        if self.driver.configuration.image_upload_use_internal_tenant:
            internal_ctx = context.get_internal_tenant_context()
            if internal_ctx:
                # it will be override
                image_volume_context = internal_ctx

        # create a image volume, but use internal_ctx
        image_volume = self._clone_image_volume(image_volume_context,
                                                volume,
                                                image_meta)
        ...

        # the image volume would belong to internal tenant, just like the admin that is often used
        # ok, that's fine, it's still look like normal
        image_volume_meta = {'image_owner': ctx.project_id}
        self.db.volume_metadata_update(image_volume_context,
                                       image_volume.id,
                                       image_volume_meta,
                                       False)

        # But in the code below, When updating cinder_url to image_location, the token will be the token of the internal_tenant

        uri = 'cinder://%s' % image_volume.id
        image_registered = None

        # retrieve store information from extra-specs
        store_id = volume.volume_type.extra_specs.get('image_service:store_id')
        location_metadata = {}

        if store_id:
            location_metadata['store'] = store_id

        try:
            # Image will not be found, because it's internal_tenant token
            image_registered = image_service.add_location(
                ctx, image_meta['id'], uri, location_metadata)
            LOG.debug("Registered image volume location to glance , response=%s" % image_registered)
        except (exception.NotAuthorized, exception.Invalid,
                exception.NotFound) as e:
            LOG.exception('Failed to register image volume location '
                          '%(uri)s.', {'uri': uri})
```

So ,I think it should be modified, use copy.deepcopy to aovid this situation. `image_volume_context = copy.deepcopy(ctx)`

ok, Even though I am using the admin user as internal_tenant, but in the Glance，it only uses the admin user as a normal user and will not find images previously created by other tenant.

my openstack version is wallaby, but the master still like this

[李亚冲 (879228763-6)]

I think I know why internal_tenant is used. If I am an administrator, I don’t want non-admin users to know that there is such a process. This will cause non-admin users to ask questions - why are there these and other things in my cloud disk list? Cloud disk starting with 'image-'.