Add no_tcpdelay_for_scan_topic parameter

[rfeistenauer]

---

Adding parameter to be able to remove occasional delay in scan topic

Info	Add parameter to disable nagle's algorithm in tcp communication
Ticket(s) this addresses	...
Primary OS tested on	Ubuntu
Robotic platform tested on	...

---

Description of contribution in a few bullet points

• I added a no_tcpdelay_on_scan_topic parameter
• This parameter gets passed to the scan topic subscriber as a transport hint
• This disables the nagle's algorithm which otherwise causes a jitter of about 20ms in the scan topic

Description of documentation updates required from your changes

• Added new parameter, so need to add that to default configs and documentation page

Future work that may be required in bullet points

• I did notice, that changing the order of imports in slam_toolbox_common.hpp to be alphabetically results in an build error due to getYaw double declaration in tf and tf2. Someone might want to investigate that ^^

Reason

During the investigation of some artifacts in maps generated with our scanner we realized the 20ms jitter in the ros topic and were able to trace the origin back to the nagle's algorithm. This is some tcp optimization which basically holds smaller massages back as long as other messages are still not confirmed. This algorithm can in cpp only be deactivated by the subscriber => in for example the slam_toolbox. This jitter was in the end not the reason for those artefacts in the map generation, but we are still wondering if you ever considered if or how it affects the localization and or map generation.

[SteveMacenski]

This jitter was in the end not the reason for those artefacts in the map generation, but we are still wondering if you ever considered if or how it affects the localization and or map generation.

Nope it shouldn't. We use everything to be carefully timestamped and use those timestamps to transform poses into the correct frames to give to the slam problem along side the data. Given SLAM runs only every few seconds / after moving N meters, 20ms is really not anything worth optimizing for here.

Closing PR, but thanks for the contribution, just doesn't actually impact the program's performance and adds a feature that isn't begging a tangible problem.