Add backend hint to the configuration information

[xtor]

Related to this PR, specifically to decoupling the backend selection from the implementation:
https://github.com/Avnu/detd/pull/20/files#r1582042749

Please note that detd will still default to the most sensible (e.g. hardware accelerated) setup by default. This class is intended to allow to override that configuration.

This class allows the customization of the specific implementation of the traffic specification and qos provided in the configuration. Based on the hint and the device capabilities, the initialization sequence will instantiate the specific classes to implement it. E.g. it may decide to use specific mappings, taprio modes, etc.

This ticket only contains the changes to provide the info an get that to the InterfaceManager for usage.

The processing of the hint to implement the specific spec/QoS will be described in a separated ticket.

Task 1: add new class Hints

We introduce a new class Hints. This class allows to select how the traffic specifications have to be implemented. It just holds the following attributes, with the described possible values:

• tx_selection: ENHANCEMENTS_FOR_SCHEDULED_TRAFFIC, STRICT_PRIORITY (mention in the docstring that EST is 802.1Qbv)
• tx_selection_offload: true, false (mention in docstring that true means that a Hardware offload for the tx_selection mechanism must be used, as opposed to a software based one)
• data_path: AF_PACKET, AF_XDP_ZC (mention in docstring that other options can be added for the data path, e.g. DPDK)
• preemption: true, false
• launch_time_control: true, false

We may add a class Hints in the scheduler module. This is a temporary location to enable the merge of the PR:
#20

Task 2: provide a default Hints class per device plugin

Each device plugin will provide a default Hints instantiation that will define how the traffic spec / QoS will be implemented if no other Hints are provided by the caller.

It should be possible to calculate the default hints based on the device capabilities, so a method could be added to device fr that. But it should also be possible to override it. Other parameters would depend on the framework as well, like the AF_XDP_ZC or other data path implementations.

Plugin	TxSelection	TxSelectionOffload	DataPath	LaunchTimeControl	Preemption
I210	Qbv	false	AF_PACKET	false	false
I225	Qbv	true	AF_PACKET	false	false
EHL	Qbv	true	AF_PACKET	false	false

Task 3: provide a default parameter flow until InterfaceManager

If the Configuration constructor contains a hint, it will be assigned to Configuration.hints
Otherwise, the default value will be None

This hints value will be directly passed through without further processing across Proxy, Service, Manager and up to InterfaceManager. E.g. no change to the hints will be made on its way to InterfaceManager.

The InterfaceManager will have an attribute hints, that will be initialized to the default hints for the device associated to the specific interface.

When a new talker or listener is added:

• If hints is None, the hints associated to the InterfaceManager will be used (e.g. left unmodified)
• If hints is not None and no other talker or listener has been added: the InterfaceManager hints will be updated to the user provided ones
• If hints is not None and there are already talkers or listeners added, and the InterfaceManager hints is different than the one provided by the user, the operation will fail, and the user will be informed via a logging message