Fixed storage account keys example

[clehene]

No description provided.

[coveralls]

Coverage remained the same at 41.862% when pulling e282c0a on clehene:patch-1 into 33e7180 on Azure:master.

[lmazuel]

Hi @clehene

You are right, I forgot to update readthedocs. I just made it:
cee8ae4

Thanks!

[clehene]

@lmazuel I closed the PR because it was incomplete / incorrect. However why not just leave it (and the test) with .keys[0].value instead ['key1'] and skip the map creation altogether

[lmazuel]

By using keys[0] I don't know if I use the key1 or key2. Even if it's not really critical, the right way to migrate from .key1 to the new API is to build a map a explicitly get ['key1'].

[clehene]

@lmazuel ouch! I was assuming keys[0] name is key1. Is this captured in the documentation somewhere? If not it would be useful to explicitly mention what's going on, to avoid wrong assumptions (such as mine) :)

[lmazuel]

As you can see here, the Storage 2016-01-01 API Version has changed from fixed "key1"/"key2" key names to a list of key objects where "key1"/"key2" are just regular name:
https://msdn.microsoft.com/en-us/library/azure/mt163589.aspx

This open the possibility in the future to decide to choose a customized key name (I don't say it's in any roadmap, just that this is now possible to think about it).

This means that even if the example shows the list in the "key1"/"key2" order, this is not a requirement and the object order in the list might changed in the RestAPI answer. In addition, the order might be changed by the implementation and might be inconsistent between C#, Java, Python, etc.