Challenges w.r.t. uploading multiple Versions

[duglin]

Challenges:

• When doing a PUT/POST on a Resource, when do we apply the Resource's (default version) properties? Related to order of processing ?setdefaultversionid + POST /versions on a resource that was just added to spec
• What if the default props differ from the corresponding Version's props?
• If ?setdefaultversionid can not be used (e.g. uploading multiple Resources), how does someone set it? Same for sticky flag

Proposal: Assume the input is the desired state of the system, at least within the scope of the data provided (no auto-deletes); the processing should result in it looking like they did things in this order:

1. If ?inline is present, upsert any Versions in the "versions" collection

2. If the Resource is part of a collection of Resources in the request message (e.g. / or /GROUPs/gID or /GROUPs/gID/RESOURCEs ) then:

   • Apply defaultversionid Resource property if present on that Resource
   • Apply stickydefaultversion Resource property if present on that Resource - Concern: sometimes readonly props aren't readonly

3. If the Resource is not part of a collection (e.g. /GROUPs/gID/RESOURCEs/rID ) then:

   • Apply ?setdefaultversionid query parameter, if present

4. Apply Resource properties to the current default Version IFF default version is not in the "versions" collection This means that any diff between Resource and Version, Version wins

If epoch doesn't match on any Resource or any Version, error

Add support for these on PUT & POST operations:

• ?noepoch - turn off epoch checking
• Only when ?inline is used
  • ?nodefaultversion - only apply defaultversionid properties if no default version is already set (e.g. a new resource)
  • ?nostickydefaultversion - turn off applying the stickydefaultversion property, if present (perhaps this should just be merged into the previous one)

Is it bad that we're inconsistent in that we support setting the "default" properties via json when the resource is part of a collection, but not when it's stand-alone (we require the ?setdefaultversionid query param be used)?

These flags allow people to GET and the POST w/o having to touch the data to remove epoch and the defaultVersion properties, if they don't want to them to be applied

Note: this is related to #88 - once we figure out how to order the uploaded versions, that decision might influence how we deal with the concerns here.

[duglin]

As of today, the spec says this w.r.t. setdefaultversionid query parameter:

- Aside from the special values of `null` and `this`, its value MUST be
  the `id` of a Version for the specified Resource after all Version processing
  is completed (i.e. after any Versions are added or removed). Its value is 
  not limited to the Versions involved in the current operation.
- When the operation involves updating a Resource's "default" Version
  properties, the processing of the `setdefaultversionid` parameter MUST be
  done before the properties are updated. In other words, the Version updated 
  is new default Version, not the old one.