`storage.key.Key`: add direct support for additional resource fields

[tseaver]

The Object API resource representation defines a number of fields as "writable":

• acl[]
• cacheControl
• contentDisposition
• contentEncoding
• contentLanguage
• contentType
• crc32c
• md5Hash
• metadata{}
• name

Key.from_dict currently captures them all in the key's metadata attribute, but that name creates confusion with its metadata key (which stores application-defined key-value pairs).

I think it would be cleaner to map each the non-user-defined fields onto separate attributes, and propagate them to the server via the insert, and patch or update endpoints.

Key should also expose read-only properties for the non-writable resource fields not already mapped, and which aren't constants:

• componentCount
• etag
• generation
• id
• mediaLink
• metageneration
• owner{}
• selfLink
• size
• storageClass
• timeDeleted
• updated

[dhermes]

Is there some sort of existing implementation to compare against? I'm all for renaming the metadata dictionary as something else to clean up the namespace, but implementing all of these seems like it should be done carefully (hence learning from existing would be useful).

[tseaver]

I don't know about other implementations. This issue (and the parallel one for Bucket) are pointing out gaps where we don't fully expose the API. It would be fine for @silvolu to say, "don't worry about those gaps for M1".

[silvolu]

I think we should take action on both, but let's switch to apitools first, and then we'll get back to this issue.

[silvolu]

It's fine to do this now, see #343 (comment)