move all subkernel message handling to aux channel

[sbourdeauducq]

• revert DRTIO RT modifications made in Subkernels calling subkernels on other destinations, subkernel DDMA, with bidirectional DRTIO routing #2291
• refactor handling of aux channel in firmware to support concurrent/async transactions
• move all subkernel message passing to aux

[Spaqin]

For an additional explanation why #2291 has used main DRTIO protocol to indicate that 'async' messages are awaiting in the satellite below.

Originally, the aux protocol ran with these assumptions:

• all transactions are initiated by master,
• transactions always go from master to one satellite,
• downstream satellite is always ready to receive,
• all transactions goes from master to downstream satellites, never upstream,
• only one transaction is open at a time.

And that's it, quite simple.

However, since DDMA and subkernel support were added, it got a bit more complicated. DDMA would finish work and would need to indicate its status, and subkernels can initiate various transactions on their own to various destinations. And of course we value our time - initially DDMA status would be sent along with DestinationReply, which is sent periodically every 200ms; with subkernel activity or larger data that needs to be broken down, that could be way too long.

With the current simple system in place, messages cannot be sent upstream blindly: the master or repeater may be busy handling something, not pick up the message on time, and if another one comes before that one is copied away, the new message is lost. Even downstream has to take into account processing time, if a response is not expected, before sending another message.

That's why as a quick fix a flag that messages are pending was implemented with the main channel was implemented.

With asynchronous messages and concurrent transactions, the state of the satellite will also have to be taken into consideration; and doing it within the aux protocol without hardware flow control, will have to overcome the following challenges:

• clearing the pathway for the next message as quickly as possible, if possible separating receiving message and handling it,
• making sure no packet gets lost in both upstream and downstream directions,
• minimizing the number of potential message retransmissions,
• keeping the latency as consistent and low as possible.