Rework systemd service state to reflect complex dependency tree and spilt between setting and runtime state

[mame82]

Currently the state of the systemd service is only partialy stored in an hierarchical object, parts of the state are stored in global variables. The structure doesn't account for the need to split everything state in runtime settings and runtime state (f.e. the DHCP server configuration of an interface is a setting which could be changed at runtime, but DHCP leases handed out to clients belong to a kind of runtime state).

Additionally there're complex dependencies in state changes, which are arising mostly from USB gadget as a root element. These dependencies have to be recorded in a state tree and used to build a new state object.

Example:
Assuming that an USB gadget with keyboard, mouse, rndis and serial functions is active and the user wants to disable the serial function, the following dependencies arise:

1. Changing the active USB functions involves destruction and recreation of the whole composite gadget.
2. Once the gadget is destroyed, the logical RNDIS interface on P4wnP1 disappears.
   1. Service attached to the RNDIS interface have to be suspended or terminated, f.e. a running DHCP client or server.
   2. If a DHCP server is running (external process dnsmasq managed by P4wnP1) all client leases are lost and clients have to re-request them.
   3. The interface goes up again, former running DHCP related processes (server/client) have to be restarted, with the last known configuration.
3. When the gadget is destroyed, additionally the HID devices like keyboard and mouse go down.
   1. The HIDController has to be stopped, as it tries reading the LED state of the USB host in an endless loop with blocking IO. Before the HIDController is restarted, the new device file to read Keyboard LED reports from, has to be redetermined (could change during USB reconfiguration)
   2. Stopping the HIDController, means all the currently running HIDScripts (managed by the controller) have to be interrupted (in fact they are terminated).
   3. Processes not managed by P4wnP1, but relying on HID functionality have to be terminated, too, as it couldn't be assured that USB HID functionality will be reestablished with the same device files. (f.e. the python based server for HID covert channel, which relies on presence of raw HID device). In fact every service depending on HID has to be managed by P4wnP1 to solve this and thus has to be part of the run-time state.

ToDos:

• design a dependency tree (visualization), holding all run-time settings and state
• create a data structure for the systemd service, reflecting this tree (could be done in proto file, to allow easy gRPC usage)
• deploy getters and setters for state changes, to have an entry point for event generation available
• check if dependent actions could be triggered using events, instead of propagating along the tree (decoupling)

[mame82]

Redesigned