Send v1 requests to v1 receivers even if v2 feature is enabled

[DanGould]

This is the last component missing from full backwards compatibility

For example, if you make a v2 request and the response says version unsupported but returns a v1 supported, then you should retry with a v1 request which you can make with extract_req_v1()

[DanGould]

blocked by #120 in order to parse versions supported

[jbesraa]

if the user has v2 feature enable, they cant use the no(v2) features right? how would we construct v1 if the context they are in is v2 ? another wonder, in testing this, the test should allow v2 and non v2 features(the sender should have both, the receiver should have only non v2), and that sounds tricky.

[DanGould]

Tricky but I have done it for this project before, e.g. compile two separate payjoin-cli binaries with their own features. But you shouldn't have to do that.

I believe since v2 feature should is able to service v1 requests, an integration test can do some manual error propagation to trigger the version mismatch and then both sender and receiver operate with the v2 feature enabled over a relay using v1 messages.

[DanGould]

It seems like the RequestContext::extract_v1 returns a tuple containing the ContextV1, so if that path is used then ContextV1::process_response can be called in the case when calling a v1 receiver.