Discussion: Reconsidering requestor pausing

Currently, we have an implementation of requestor pausing that works as follows:
- Requestor can be paused in a block hook or a imperatively (calling PauseRequest on graphsync with a request ID)
- "Pausing" works by simply cancelling the request. "Resuming" works by resending the request with DoNotSendFirstBlocks

IMHO, this is ridiculous. The reason I did it is that I wanted the requestor to stop accepting blocks entirely as soon you paused. This once upon a time approach was based on trying to get payment channels to work for data transfer push requests. (see https://github.com/ipfs/go-graphsync/issues/346 for explanation).

I believe the proper way to do this is:
- add a Pause request type -- see https://github.com/ipfs/go-graphsync/issues/345
- have the responder when it receives a pause request pause the response and send back a ResponsePaused code
- requestor keeps receiving data until pause response is received.
- PauseRequest imperative call blocks until roundtrip completes

Questions:
- does this make sense?
- should this require some kind of validation? when I download stuff over HTTP, I don't seem to require anyone's auth to pause & resume?
- what happens if the responder never sends back a pause?
- should a responder time out a paused request that was paused by the requestor after certain amount of inactivity? (protect against dosing with lots of paused requests)
- should we remove pausing on the requestor side entirely -- move it to simply sending update requests with extensions and letting the responder pause if it wants to?
- What about requestor resuming? Do we need a resume request type as well?

Why should we have imperative requestor pausing?

- I'm not sure it's used today, but it certainly makes sense from a the standpoint of being like HTTP. If one imagines a download manager, one certainly imagines the ability to hit a pause button