endpoint: Server-side bundle awareness

[erichanson]

Right now, the REST API is just an interface to view/change the state of things right now (CRUD). But with version control now in place, there's a lot more awareness and intelligence available to integrate in. We need to integrate bundle-awareness into endpoint, generally. #72 touches on it but it is just the tip of the iceberg.

Examples of where it would be nice/essential:

• Building the commit history inspector. Right now there isn't a good way to see what was in a particular bundle at a particular commit without checking it out.
• Widget copy in the IDE - The row isn't being tracked in the current bundle, it goes into the untracked row heap instead, because I didn't write a bunch of boilerplate to track the copied row. Should just be a flag.
• Looking at version history of any row. There should be an API for this, not a bunch of client-side garbage code that one-offs inspecting the commit tree over and over

Operational changes:

row_insert / rows_insert

Needs the ability to specify that the new row should be tracked, staged, or maybe even committed, and by which bundle. Track-on-insert is very often the desired behavior. Stage-on-insert is less common but seems like it could be useful. Commit-on-insert is weird, but we might as well make the option available for say a streaming database or a commit-based chat.

The above could also be accomplished, alternately, by setting up table-wide auto-tracking rules: "All inserts into this table are tracked by this bundle." Not sure this is a good idea though, because nobody "owns" a particular media type. Could be useful in a single user environment.

row_update

Updating a row that is in a bundle (tracked) could auto-stage the update. Not much here.

row_delete / rows_delete

Deleting could also auto-stage the delete. Also uninteresting.

row_select / rows_select / field_select

endpoint.row_select() takes a row_id, but it could also take a commit_id to grab the value at a previous commit, or a modifier that says "give me the HEAD version, not the working copy version." It could take version ranges (once we have version tags), etc. rows_select takes an args object for things like where clauses, which would be very strange to handle because it would need to somehow run a where clause against a not-checked-out version. Might be challenging. Checkout + rollback?

rows_select_function

This could actually take a previous version of the function which would be pretty crazy. Not sure how to pull that off though.
Or it could run against a previous version of the database. Also quite complex.