Currently, applications that use LiteFS need to write some LiteFS-specific code to redirect requests to the primary and to maintain consistency with the TXID after a write. It'd be useful if LiteFS could provide its own thin HTTP proxy in front of the application that would do the following:

1. Redirect non-GET requests to the primary node.
2. Inject a cookie (or other mechanism) for tracking the current TXID after a write.
3. Wait for a replica node to catch up to the client's tracked TXID.

With these features along with write forwarding (#56), most applications should not need to have any knowledge about LiteFS.

@kentcdodds Can you think of any other LiteFS-specific application code we could get rid of with a thin proxy?