Description of problem:
When attempting to attach a subscription from multiple pools of similar layered products activation keys aren't flexible enough. 


Version of components:
katello-2.2.0.19-1.el7sat.noarch


Detailed problem statement:
Activation keys in Satellite 6.1 support 3 basic use cases

[1] provide a list of subs and run auto-attach against the list
[2] provide no subs & run auto-attach (basically run subscription-manager attach --auto-attach)
[3] provide a list of subs and attach ALL of them. 


Consider the following Satellite with these subscriptions. 

hammer --output json subscription list --organization "$ORG"
[
  {
    "Name": "Resilient Storage",
    "Contract": "********",
    "Account": "********",
    "Support": "Layered",
    "Quantity": 100,
    "Consumed": 0,
    "End Date": "2016-08-05",
    "ID": "2c91809352db8ab10152db91919a0cc0",
    "Product": "Resilient Storage",
    "Attached": 0
  },
  {
    "Name": "Resilient Storage",
    "Contract": "********",
    "Account": "********",
    "Support": "Layered",
    "Quantity": 50,
    "Consumed": 0,
    "End Date": "2017-11-05",
    "ID": "2c8b6681cf44b9bfa7eb97fbea5afb",
    "Product": "Resilient Storage",
    "Attached": 0
  },
  {
    "Name": "Red Hat Enterprise Linux for Virtual Datacenters, Premium",
    "Contract": "********",
    "Account": "*******",
    "Support": "Premium",
    "Quantity": 6,
    "Consumed": 0,
    "End Date": "2016-08-05",
    "ID": "2c91809352db8ab10152db91363e04f3",
    "Product": "Red Hat Enterprise Linux for Virtual Datacenters, Premium",
    "Attached": 0
  }
]

Due to my organizations purchasing policies/sales motion/renewal/whatever, we have purchased two groups of Resilient Storage (RS) subscriptions. When provisioning a new RHEL virtual system, I don't really care which group of (RS) subscriptions are used, but I'd like to ensure that when provisioning a node, it has one.  

Today, this is impossible to do:

First and foremost, best practices (https://access.redhat.com/articles/1554633) for using an activation key state to use an activation key with 'auto-attach=true' and no subscriptions attached to register the virtual systems to consume RHEL via vDC. That part works. The challenge is how do I attach exactly 1 RS subscription in addition to the RHEL subscriptions. I'd like to use this first key to attach a RHEL sub, and an additional key to attach the layered product, and provide both at registration time. 

* if I use the use case as described in [1] - 'provide a list of subs and run auto-attach against the list', I create a key with 'auto-attach=true' and both sets of RS subs attached. This key fails to have the desired result because the nodes at registration time do not have any Resilient Storage bits installed, so there is effectively nothing (90.pem doesnt exist in /etc/pki/product) for auto-attach to attach to. 

* if I use the use case as described in [2] - 'provide no subs & run auto-attach', I create a key with 'auto-attach=true' and no subs attached. This key fails to have the desired result since it is effectively the same as running 'subscription-manager attach --auto' and again, 90.pem doesn't exist, so auto-attach cannot attach a Resilient Storage subscription. 

* if I use the use case as described in [3] - 'provide a list of subs and attach ALL of them.', I create a key with 'auto-attach=false' and both sets of RS subs attached. This key fails to have the desired effect as the node will get 1 subscription from *each* pool attached. The system would have too many Resilient Storage subscriptions attached. 


Expected results:

I would like to see the activation key extended with the capability for the end user to define/force a Red Hat product certificate to be installed, even if bits from that products repositories haven't been installed yet. That is, allow me to say 'Resilient Storage is going to be installed on this system, run auto-attach as if it was installed already'. This would allow the [1] use case to work and provide me with exactly the 1 subscription that I desire. 

Additional info:

Today, I can workaround this, by extracting the product certificate for Resilient Storage from a working system (or from the repo) and placing it in /etc/pki/product/ prior to registration and using a use case [1] key, but this is kinda hackish and isn't sustainable. 


For what it's worth, this BZ is effectively the activation key version of  [RFE] request for subscription-manager to support attaching a matching subscription (https://bugzilla.redhat.com/show_bug.cgi?id=1210294)