Opening channels in both direction in one go #3545
Description
HRMP as well as XCMP supports channels only in one direction. Right now, there is logic only for opening a channel in one direction: from one party to another. In case communication is required in both directions the parties should go through opening the channels, i.e. creating a request and accepting it, twice.
Bidirectional communication seems to be a common enough case that it deserves it's own simplified way. Specifically, one confirmation from either side should be enough to create channels in both directions.
This probably will look like as follows. We have another list of open channel request specifically dedicated for this case. The request will be identified by a tuple which contains both sender and recipient.
Unlike the unidirectional channels, there will be no initiating party. Therefore, the tuple should be the same whether a para A initiates the request or B. A simple way to achieve that is to make the first tuple item a para with the lower numerical para ID and the send with the greater.
When the counterparty sends the corresponding message (perhaps even of the same kind) then the channel can be opened at the next session change.
The initiator will leave two deposits: one for where the initiator is the sender and one for where it's the receiver. At the time when counterparty leaves the deposits in the same manner.
Canceling of the request is only possible before the request is accepted. Either of the parties should be able to cancel the request.
Participating in the request should be counted as 2 channels towards the channel limit.
When either of the parties para offboards, the request should be removed. That implies there is a mapping between parachains and the bidirectional channels open requests. In case there is an accepted request it is ignored. The deposit is not returned to the offboarded party, but should be refunded to the para that is still live (see also #3544)