WIP: tighten identifier spec 

DO NOT MERGE YET

There are still a couple open questions.  As I read through it I wanted to wordsmith a bit, which lead to reordering some to read sort of top-down.  There were a couple things I thought were wrong (pod name should be a subdomain) and a few things I think we can make more concise.  I also added examples and clarifies corollaries.

@smarterclayton in particular


Fair point on cleanup - if you aren't waiting or handling a return locator you probably want to specify a name.  If you are waiting, it's not an issue.  However, if you aren't waiting until you at least know that the element persists, doesn't that just complicate API consumer's lives even more?

Right now pod_storage blocks the return until the item ends up on a host, which could be a very long time, or you can't get the error right away.  I would argue that the two intervals that an API consumer expects is

1) Is my request accepted (is it internally consistent and has the server acknowledged it)
2) Has the request taken affect in the rest of the system

I would expect the pod_storage API to block create until 1) has completed, but not 2).  2) seems like the responsibility of a higher level layer - especially since a node could be taken away in between when we schedule and invoke the first request, but before the container successfully starts.  In that case you might even see a reschedule occur there.  Seems like the <-chan interface on pod_storage should be on commit to stable storage, not placement and execution.