Implement lock free ring buffer with throttling [NOETIC]

[Samahu]

Related Issues & PRs

• Closes Missing lidar chunk os1-128-u  #240
• Closes Parts of point cloud missing #272
• Related Atomic refactor for lock-free ringbuffer [Foxy] #302
• ROS2[FOXY]: Implement lock free ring buffer with throttling [FOXY] #320
• ROS2[HUMBLE/IRON]: Implement lock free ring buffer with throttling [HUMBLE/IRON] #321

Problem Analysis

• When adding multiple subscribers or when having a bad network or low performing system, LidarScan composition and processing could eventually take more time, this leads to a build up in the packets buffer which will eventually be exhausted and the current mechanism of the thread_safe_ring_buffer::write_overwrite made things only worse. The solution can be in one of two things either ensure that the LidarScan composition + processing takes less time than the time needed to add new packets, or decouple packet addition from LidarScan consumption, if the consumption thread can't keep up then throttle.

Summary of Changes

• Implement lock free ring buffer with unit tests
• Decouple packet reception from packet processing
• Throttle the ring buffer as we reach 70% capacity
• Drop packets only when the ring buffer has been completely exhausted

TODO(s):

• Replace the LockFreeRingBuffer implementation with ThreadSafeRingBuffer within os_sensor_nodelet.
  • Alternatively, forward the packets directly to LidarScan without a staging buffers.

Validation

• Run the driver as usual with RIVZ, add multiple subscribers to /ouster/points
• Verify the problem with missing columns is eliminated or reduced.
• Observe that the point cloud publish frequency isn't affected significantly