Decouple ReplicationTransfer and BagManRequest models

[dazza-codes]

Extracted from #77 (review)

The control flow, transactionality or atomicity, of the cancel! operations between the ReplicationTransfer and the BagManRequest are complex because they each call the other and, without the unless cancelled statement, might incur an infinite loop. I wonder whether the calls from one model to the other should be extracted out of the models, to allow an atomic update of one model and then another model? Perhaps this coupling between these models should be extracted from the model level up to the controller level? An additional decoupling would be to have a client manage all aspects of the BagManRequest update, to provide or manage eventual consistency with the DPN REST API updates for ReplicationTransfer.

[dazza-codes]

This can be addressed after #83

[malakai97]

Hathi is now using an implementation that completely eliminates BagManRequest. I recommend using that going forward. Putting this on hold.

[Pcolar]

Does your change alter the replication state diagram? Assuming it was correct to begin with...
I would like to work with you to complete this documentation.
https://www.lucidchart.com/invitations/accept/60d79689-313d-4464-96fc-dfe4d8d638d1

[dazza-codes]

There is also decoupling of the REST API and the bag transfers by using the https://github.com/dpn-admin/dpn-sync project.