Make usage of expensive (= relayed) connections in high level protocols such as request_response configurable

Description

P2pCircuit (relay) connections should be considered expensive due to bandwidth limitations. They should probably only be used for control plane data exchange (such as Dcutr). But this cannot be easily implemented using the current implementation of request_response.

Motivation

For me, request_response would become a lot more usable if the Behaviour itself could be made aware of expensive connections. Perhaps something more general than "relayed or not" could be done, but even that would be great to start out.

Afaik at least the JS implementation acknowledges this by making whether or not a request should be send over such connections configurable.

Current Implementation

The Rust implementation of request_response completely abstracts the dialling process away from the user, making it unusable as soon as Dcutr and relays (or "conditional data transfer") become relevant.

I see no reasonable way to fix this in my app, so this goes onto the list of awkwardly patched issues in my fork of libp2p (because I don't have time or skill to properly fix this).

Are you planning to do it yourself in a pull request?

No

Start with the Rust request_response behaviour and its dialling abstraction, then compare the JS implementation's configurability for relayed connections. Trace how P2pCircuit and Dcutr interact with request_response; done means defining a supported way for the behaviour to control or avoid expensive relay connections.