[6pt, 8pt] implement selector block/node (switch matrix like run-time plumbing between input->output ports)

[ivan-cukic]

No description provided.

[ivan-cukic]

Requires dynamic ports definition or a vector<same_input_port_type>

[RalphSteinhagen]

Brief description: the 'selector' block is a runtime configurable switch matrix that connects arbitrary inputs with arbitrary outputs. Rather easy/trivial (switch matrix like run-time plumbing between input->output ports). N.B. The outputs are not necessarily connected, and only the tags of matching/connected ports would need to be forwarded.

Please look over the existing documentation of the existing GNU Radio block for details.

[RalphSteinhagen]

We (@wirew0rm, @drslebedev, @RalphSteinhagen) came up with one viable implementation option/solution for this problem that should be easy enough to implement and provide an intuitive and simple API to the users:

• The 'selector' block -- or any other block that supports a variable number of input/output ports -- would support and implement static ports (TI1, TI2, ..., TO1, TO2, etc.) as before. These ports can be arbitrarily strictly typed (<-> being fields of the node/block struct).
• In addition to static ports, the idea is to have a pair of vectors for the input and output ports. The Port<Tx> inside these vectors would have the same name (modulo counting index), constraints, and, notably, type (T_IN for input ports and T_OUT for output ports).

This way, the block would support the following process_bulk(...) signature:

work_return_status_t
process_bulk(std::span<TI1> in1, std::span<TI2> in2, ..., std::vector<std::span<T_IN>> dyn_in, 
             std::span<TO1> out1, std::span<TO2> out2, ..., std::vector<std::span<T_OUT>> dyn_out) {...}`

The same signature as above but with std::span<> replaced with our new ConsumableSpan<T_IN> and PublishableSpan<T_OUT> concepts.

These ConsumableSpan and PublishableSpan concepts function like std::span<T> but with an initial maximum size. The user can consume(size_t) only a partial amount of the available input and commit produce(size_t) only a partial amount of the initially reserved samples before the process_bulk function is called. This introduces the flexibility for handling varying input-to-output sample-rate ratios on the fly.

Please share your thoughts, suggestions, or potential pitfalls with this approach.

[ivan-cukic]

Planned implementation outline:

• Add the for multi-parametrized nodes in the node registration system
• Add the support for defining runtime-size-known collections of ports (vectors, lists, etc.)
• Add port grouping with per-group policy of the behaviour (synced inputs, selected inputs, joined inputs)
• Define the selector block

[RalphSteinhagen]

finished by PR: #178