Multi-threaded Camera logging refactor

[MinhxNguyen7]

Summary

• Refactor logging of camera images and metadata to the CameraLogger class.
• Simplifies the logic for starting and stopping recording.
  • In Camera, only a variable needs to be toggled, which determines whether the recording worker submits the data to the CameraLogger.
• Makes stop_logging non-blocking.
  • Previously, stop_logging would join the logging thread, which might be taking its sweet time, thus blocking on it
  • Now, the CameraLogger has a thread pool which auto-scales (up to two threads) up and down and is automatically destroyed, which means that we don't have to manually create and terminate threads.
• Honestly, I wouldn't have written this if I realized that the logging was already threaded.
  • I didn't know because the issue was still open, and I just wrote the class.
  • That being said, this is a cleaner implementation.

Test Plan

• See that logging works, testing concurrently with #226.

  Issues

• Closes #220

[Dat-Bois]

I mean it looks fine, one issue I see is that it doesn't seem you are making a queue of the images to log. The reason I did this is because the image logging runs considerably slower than getting a live frame since its writing to disk. I know you have a threadpool to do it async but if its capped at 2 threads wouldn't that mean like we have a buffer of like 2?

What I'm describing you may have solved, it might just be my limited understanding of threadpools making it seem like what I described.

[MinhxNguyen7]

The queue is implemented in the pool itself. You just need to submit to it. That's what makes it so elegant.

[Dat-Bois]

Right but isn't it only limited to two threads concurrently like you said? What happens if you want to log a frame while the other two threads are already occupied? Does the thread pool automatically hold the queue for 2+ requests?

[MinhxNguyen7]

Yes. If you call submit 3 times simultaneously, the third one is added to the queue and executed after the 1st one is done.