Was: Proposal: add non-identifying key-value metadata to API objects (aka Annotations).

Alternative forked from #1178, but I believe is independently useful.

@smarterclayton For consideration as part of API overhaul.

We currently have labels, which is map[string]string, for identifying metadata. We'll likely index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying information.

It would be useful to be able to attach arbitrary non-identifying metadata. The API server would just hold on to the information for retrieval by tools, libraries, etc. -- that is, by other API clients rather than the managed application's containers themselves.

I suggest adding another map[string]string in whatever our API object base is (currently JSONBase). The values, at least, should be liberal with allowed characters, sufficient to permit JSON, for instance.

The immediate use case I have in mind is to store the configured desired state of each object, but other use cases include:

• build/release/image information (timestamps, release ids, git branch, PR numbers, image hashes, registry address, etc.)
• pointers to logging/monitoring/analytics/audit repos
• client library/tool information (e.g. for debugging purposes -- name, version, build info)
• other user and/or tool/system provenance info, such as URLs of related objects from other ecosystem components
• lightweight rollout tool metadata (config and/or checkpoints)
• phone/pager number(s) of person(s) responsible, or directory entry where that info could be found, such as a team website

Yes, this information could be stored in an external database, but that would make it much harder to produce shared client libraries and tools for deployment, management, introspection, etc.