Merge lp://staging/~harlowja/cloud-init/launch-index-work into lp://staging/~cloud-init-dev/cloud-init/trunk

Josh,
 Thanks for the work, it looks pretty good. I have a few comments:
 * why CAN_HAVE_LAUNCH_INDEX ?
   why do we want to limit which parts can affect only a given launch index.
 * https://review.openstack.org/#/c/11997/ will add 'launch_index' to the openstack metadata service. I suggest we make the getter for launch_index a default in DataSource and let ec2 override it. The default would look for 'launch_index' or 'launch-index' in metadata and return None if not found.

> Josh,
> Thanks for the work, it looks pretty good. I have a few comments:
> * why CAN_HAVE_LAUNCH_INDEX ?
> why do we want to limit which parts can affect only a given launch index.
> * https://review.openstack.org/#/c/11997/ will add 'launch_index' to the
> openstack metadata service. I suggest we make the getter for launch_index a
> default in DataSource and let ec2 override it. The default would look for
> 'launch_index' or 'launch-index' in metadata and return None if not found.

So CAN_HAVE_LAUNCH_INDEX is more of just a filter that restricts whether we will look into there payload to see if it has a 'yaml' body that has a key 'launch-index', the individual parts can still provide there own 'Launch-Index' header (since it seems bad to scrap all content that might not be yaml). That seems to make sense, although it can be disabled if we want.

As far as the getter, can do, let me make it a property that does that.