Uniqueness of ACLs with Keystone V3

Currently Swift API allows granting access by providing either a tenant name or ID on ACLs. With the introduction of projects and private domains in Keystone V3 this will become a project name or ID, where only the project ID is globally unique. When migrating existing deployments to Keystone V3 there is a need to ensure that the descriptors on ACLs are unique and a user from domain A, working on project "myproject" can not access the data of a user from domain B working on a different "myproject". There might be existing applications working above Swift using project names and not IDs. To allow backward compatibility and preserve a user friendly option of project names, a domain identifier (in a form of an optional x-domain-id header) will be added to container metadata. During the container creation process, this identifier will be extracted from the token of the creator and added to the container meta data. When evaluating the ACLs and comparing the project name on ACLs with the one in the token of the accessing user, the acl.py middleware will check that the container and the user belong to the same domain. If the ACLs are ambiguous and do not uniquely identify the project, cross domain access will be denied. In order to allow cross domain access, there will be a need to explicitly specify a unique project ID on the ACLs. These changes will not influence the systems working with other authentication middleware (e.g. tempauth).