Redesign multiplexing

[bjoerntm]

One could discuss changing the multiplexing architecture as follows:

• there is no explicit multiplexing identifier,
• instead, an outside process can register to receive all messages from the multiplexer,
• and (for each message) decide whether it is the supposed receiver.

This has advantages:

• the multiplexing identifier must now be handled by multiple layers (the multiplexer, of course, but also the identifier must be sent as part of the initial message to the client, so one could argue it crosses layer boundaries),
• the current design has very static multiplexing identifiers, and other schemes (e.g., pseudo-random identifiers) have the potential to preserve more anonymity (or: destroy less anonymity).

It also has disadvantages:

• if there is a slow server process, and a fast server process that receives a lot of data, then the slow process will make the buffers fill up quickly, unless there is a clever timeout mechanism,
• it requires clever implementation if we do not want to pay the price of copying the data for each server process.

[bjoerntm]

This seems to hint at the following: MultiplexingID should probably not be in an api package, but rather in an impl one, since it is an implementation detail of the multiplexing scheme.

In particular, this would also mean breaking up the IdKeyPair, since this is actually something that breaks the layers. The key establishment should, well, establish a key, and if we want to assign an ID for a higher-level protocol we can still easily do this in the next layer. (I am aware that this is currently interleaved with the multiplexer and may imply some restructuring there.)