NOTES ON PUSH

       If the remote storage (RT) can not represent a whole changeset along with the prophet
       changeset uuid, then we need to create a seperate locally(?) stored map of:
           remote-subchangeset-identifier to changeset uuid.
           remote id to prophet record uuid

       For each sync of the same remote source (RT), we need a unique prophet database domain.

       if clkao syncs from RT, jesse can sync with clkao but not with RT directly with the same
       database.

       Push to rt algorithm

       apply a single changeset that's part of the push:
           - for each record in that changeset:
               - pull the record's txn list from the server
               - for each txn we don't know we've already seen, look at it
                   - if it is from the changeset we just pushed, then
                       store the id of the new transaction and originating uuid in the push-
       ticket store.
                           - does that let us specify individual txns? or is it a high-water
       mark?
                    - if it is _not_ from the changeset we just pushed, then
                       do we just ignore it?
                       how do we mark an out-of-order transaction as not-pulled?

       Changesets we want to push from SD to RT and how they map

       what do we do with cfs rt doesn't know about?

       SD::Source::RT->recode_ticket