packet_type cannot be changed effectively during runtime

[kawk]

Changes to driver parameter packet_type during runtime are handled inconsistently. The driver does update the sensor with set_scanoutput_config, but internally keeps its packet_type-specific parser instance for the old type, which is then not able to correctly parse the incoming data anymore. Scan data publishing ceases.

To Reproduce

1. Launch the driver set up to request packet type 'C' from a R2000, verify that it is publishing scan data
   ros2 topic echo /scan
2. Change desired packet type to 'A'
   ros2 param set /ros_main packet_type A
3. No more scan data output
4. Change desired packet type back to 'C'
   ros2 param set /ros_main packet_type C
5. Scan data output resumes.

Expected behavior

The driver should either just reject the parameter change or adapt to the new setup and continue publishing the scan data. Doing neither is inconsistent.

Environment (please complete the following information):

• OS: Ubuntu 24
• ROS Version: Humble
• Driver: I tried revisions from before integration of feature/pfsdp-services up to now even with the fix/no-device-family integrated.

Sensor

• Device: Only R2000 (R2300 knows only one packet_type)

[kawk]

The parsing is implemented in a specialized instance of Parser<PFPacket> chosen during PFInterface::get_pipeline used by PFInterface::start_transmission called from main loop only at start or after network failures.
Thus, to adapt to changes during runtime, a "network failure" (net_fail condition variable) must be provoked in the callback handling the update or parser must be reworked to handle not just one particular packet type.
As "packet type" in principle also stands for more or less header fields, it would be consequent also to be able to adapt the header data topic publication appropriately, but that would mean a change in data type, not to be made on the fly.
Seeing these dependencies, I tend to recommend to just reject packet type change requests...