Identify mechanism for replication flow with STAC

[lliming]

Issue at present:

• No STAC backends (Elastic, postgress, SQLAlchemy) actually support a PATCH update
• The Transaction API supports in theory but the API is marked in all cases as NotImplemented
• The existing PATCH is RFC7386 compliant but:
  • This mechanism interprets explicit nulls as a DELETE statement and is stated in the RFC document to be inappropriate for data which allows explicit nulls (like STAC)
  • ElasticSearch's update is not compliant as it interprets explicit nulls as "set to null, leave in document, remove from index only"
• RFC6902 would be better as it allows explicit operations (add, remove, set) which could in theory be translated to painless scripts for Elastic Search to actually remove the source attribute

Going forward:

• Speak to STAC about RFC7386 as the mechanism for the transaction API PATCH method, as STAC's requirement for explicit nulls makes it a poor choice
• Suggest that RFC6902 may be a better bet (in fact the two could be supported simultaneously by pivoting on a "accept" header (application/merge-patch+json) vs (application/patch+json)? )
• Potentially add "alternate assets API extension" if RFC6902 is rejected as an additional mechanism, so that we can provide atomic changes.

[lliming]

This is tangentially related to #26 but it seems the two issues are independent.