## Summary
* Changed the office LAN convenience function to a class with a registry. Now, plugin can register custom node adders.
* Added ability to define `node_sets` in the config that map to `NetworkNodeAdder` subclasses
* Made airspacefrequency into a DTO class again to make management simpler.
* Moved the node registry out of `HostNode` and `NetworkNode` into `Node`
* Changed game.py to check the hardcoded node types before the node registry (this will change once I add ConfigSchema to all node subclasses)
* Made `show` method of the network container show all nodes, including ones registered at runtime.
## Test process
* Existing tests passed.
* Added unit tests for node adders
## Checklist
- [X] PR is linked to a **work item**
- [X] **acceptance criteria** of linked ticket are met
- [X] performed **self-review** of the code
- [X] written **tests** for any new functionality added with this PR
- [X] updated the **documentation** if this PR changes or adds functionality
- [ ] written/updated **design docs** if this PR implements new functionality
- [X] updated the **change log**
- [X] ran **pre-commit** checks for code style
- [ ] attended to any **TO-DOs** left in the code
DataFusionService didn't show in software list, because it uses the port_protocol_mapping as the source of truth for installed software instead of the software list itself.
This fixes that :)
Related work items: #2899
## Summary
* Ports are no longer enums, they are now plain integers
* Ports are no longer validated against a list of pre-defined ports, any integer from 0-65535 can be used now.
* Port enum was replaced with a convenience port lookup. For example any expression in the form `Port.HTTP` was replaced with `PORT_LOOKUP["HTTP"]` which resolves to the integer 80.
* Some tests were adjusted to use the new syntax for ports
* Backwards compatibility for YAML configs has been retained by adding pydantic validators to automatically convert named ports to integer counterparts, however defining action/observation spaces in code now requires users to specify ports as integers instead of port enum objects. For instance, monitored_ports in the ACL observation space will now look like this: `[53, 80]` instead of `[Port.DNS, Port.HTTP]`
* Plugins can extend the port lookup, however it is not necessary because it's possible to use integer literals.
* Airspace has been treated similarly, except airspace frequencies have multiple attributes, namely max_data_rate_bps. Therefore, the lookup for named Frequencies resolves to a dictionary of freq_hz (float), and max_data_rate_bps (float)
* Airspace logic has been adjusted accordingly to use the new dictionary for tracking bandwidth limits
* A new method for registering new airspace frequencies has been added. Plugins that add new frequencies can call `register_default_frequency`, after which any new airspace will have access to that frequency.
* For consistency, `IPProtocol` was also changed to be a lookup instead of an enum. It is not extendable by plugins as so far we have not needed to model additional protocols in our plugin.
These changes were necessary as it's not possible to extend enums in python, therefore plugins would not have been able to add new ports. There is an added benefit that this is a stepping stone towards support communication on dynamic and ephemeral ports.
## Test process
*How have you tested this (if applicable)?*
## Checklist
- [X] PR is linked to a **work item**
- [X] **acceptance criteria** of linked ticket are met
- [X] performed **self-review** of the code
- [ ] written **tests** for any new functionality added with this PR
- [ ] updated the **documentation** if this PR changes or adds functionality
- [ ] written/updated **design docs** if this PR implements new functionality
- [ ] updated the **change log**
- [X] ran **pre-commit** checks for code style
- [X] attended to any **TO-DOs** left in the code
## Summary
*Replace this text with an explanation of what the changes are and how you implemented them. Can this impact any other parts of the codebase that we should keep in mind?*
## Test process
*How have you tested this (if applicable)?*
## Checklist
- [ ] PR is linked to a **work item**
- [ ] **acceptance criteria** of linked ticket are met
- [ ] performed **self-review** of the code
- [ ] written **tests** for any new functionality added with this PR
- [ ] updated the **documentation** if this PR changes or adds functionality
- [ ] written/updated **design docs** if this PR implements new functionality
- [ ] updated the **change log**
- [ ] ran **pre-commit** checks for code style
- [ ] attended to any **TO-DOs** left in the code
#2837 - Actioning review comments following second review [skip ci]
Related work items: #2837
