litep2p/req-resp: Always provide main protocol name in responses

[lexnv]

Request responses are initialized with a main protocol name, and optional protocol names as a fallback.

Running litep2p in kusama as a validator has surfaced a debug_asserts coming from the sync component:

polkadot-sdk/substrate/client/network/sync/src/strategy/chain_sync.rs

Lines 640 to 646 in 3906c57

	warn!(
	target: LOG_TARGET,
	"Unexpected generic response protocol {protocol_name}, strategy key \
	{key:?}",
	);
	debug_assert!(false);
	}

The issue is that we initiate a request-response over the main protocol name /genesis/sync/2 but receive a response over the legacy procotol ksm/sync/2. This behavior is correct because litep2p propagates to the higher levels the protocol that responded.

In contrast, libp2p provides the main protocol name regardless of negotiating a legacy protocol.

Because of this, higher level components assume that only the main protocol name will respond.
To not break this assumption, this PR alings litep2p shim layer with the libp2p behavior.

Closes: #6581

[dmitry-markin]

Unfortunately, this is not a fix for our issue because the fallback mentioned here is actually a fallback protocol, and not a fallback name. Here we need to pass the actual name of the fallback protocol for the client code to correctly implement protocol backward-compatibility (e.g., correctly process a different protobuf schema).

I have created an issue in litep2p for adding support for actual fallback names:
paritytech/litep2p#289

[dmitry-markin]

To sum up the difference in operation of libp2p & litep2p network backends:

libp2p network backend

1. libp2p backend is responsible for sending the fallback request, not libp2p.
2. If only the fallback protocol name was used on the wire and no fallback request happened, the main protocol name is returned to the client code
3. If the fallback request was sent, the name of the fallback request protocol is returned to the client code (as it is just another protocol from the libp2p backend perspective).

litep2p network backend

1. litep2p sends the fallback request internally and it is the one responsible for actually performing the fallback request, not the network backend.

   Surprisingly enough, litep2p network backend also has the logic of handling fallback requests in case litep2p returned UnsupportedProtocol for some reason.

2. If only the fallback protocol name was used on the wire and no fallback request happened, the fallback protocol name is returned to the client code. This is what makes litep2p different and leads to panics in network/sync: Panic on unexpected generic response protocol #6581.

3. If the fallback request was sent, the name of the fallback request protocol is returned to the client code (the same as libp2p).

I will create a PR to make litep2p/backend behave in a way libp2p backend behaves.

[dmitry-markin]

itep2p sends the fallback request internally and it is the one responsible for actually performing the fallback request, not the network backend.

This turned out to be not the case: litep2p network backend does not use the litep2p's try_send_request_with_fallback and uses try_send_request instead. This means fallback requests are handled completely by the backend in substrate, and not by litep2p.

So, we can be sure that a fallback reported by litep2p is just the fallback name of the main protocol and safely override it with the main protocol name in substrate.

[lexnv]

Oki doki, thanks a lot for the detailed info and for confirming, this helps a lot🙏

[paritytech-cmd-bot-polkadot-sdk]

Successfully created backport PR for stable2407:

• [stable2407] Backport #6603 #6668

[paritytech-cmd-bot-polkadot-sdk]

Successfully created backport PR for stable2409:

• [stable2409] Backport #6603 #6669

[paritytech-cmd-bot-polkadot-sdk]

Successfully created backport PR for stable2412:

• [stable2412] Backport #6603 #6670