Bug Description

After changes made for bug 851159 [1], it seems there were some regressions in the content of the metadata service.
This is causing issues for consumers of that service (cloud-init).

Some things that are broken:
a.) kernel-id, ramdisk-id show up in the metadata service items list even if there they're not valid for this image.
The following should be empty output if there are no kernel or ramdisk:
wget http://169.254.169.254/2009-04-04/meta-data -q -O - | egrep "(kernel|ramdisk)-id"
This causes a problem when the dataservice is crawled as gets for metadata/kernel-id or ramdisk-id show 404.
b.) block-device-mapping content is broken
previously:
$ python -c 'import boto.utils, pprint; pprint.pprint(boto.utils.get_instance_metadata()["block-device-mapping"])'
{'ami': 'vda', 'ephemeral0': '/dev/vdb', 'root': '/dev/vda'}
But now,
$ python -c 'import boto.utils, pprint; pprint.pprint(boto.utils.get_instance_metadata()["block-device-mapping"])'
['ami', 'ephemeral0' 'root']

d.) if something is a dict it shoudl appear as a directory in the meta-data list
Examples of things that previously had trailing slashes but now do not:
* placement/
* mpi/
* public-keys/
* block-device-mapping/

Then, one thing which seems to have been the case before this change was:
x.) kernel-id, ramdisk-id, ami-id show 'ami-000000'
$ ec2metadata --kernel-id --ramdisk-id --ami-id
ami-00000000
ami-00000000
ami-00000000
That is that 'ami-0000000' was the kernel-id, ramdisk-id and ami-id, rather than the actual values (this was for an instance that did have a kernel and ramdisk).