Todo: update

todo

@@ -9,14 +9,6 @@
   a ref and not by-value. Propagate this upward into
   SerializedAsyncContin and into all derived classes'
   constructors.
-* In classes like udpCommandDemuxer and possibly other such background tasks,
-  use a spinlock to ensure that the stop() function doesn't deallocate the
-  data to be used by the daemon task while the daemon task is executing.
-  * Alternatively we could re-emqueue the message;
-  * Alternatively, if select/poll don't consume the read-data-rdy flag,
-    we can just return and let the next timer invocation run instead.
-  * Alternatively, we can use an xchg'd flag between the udp listener
-    and the timed enforcer.
 * In livoxProto1/device.cpp, migrate the registerUdpCommandHandler() calls
   from using the inProgress collection to the per-device collections.
 * In cases where we use boost deadline_timers and pass in an async
@@ -25,16 +17,6 @@
   after they expire just in case boost doesn't clean up the internal
   callable that we passed it. Or else we'll have circular sh_ptr
   references in our continuations.
-* Think of a unified mechanism or a design pattern which will ensure that
-  timeouts will always either expire or be canceled before program
-  finalization.
-  Or more generically, before their lifetime ends.
-  * One good mechanism is to use synchronous waits on the timeout
-    events. This is fine during program shutdown because we don't
-    need to care about responsiveness during program shutdown.
-  * We can use asynchronous bridging to ensure that asynchronous
-    events are executed in the meantime while we wait for the sync
-    timeout to complete.
 * UdpCommandDemuxer::registerUdpCommandHandler should accept a pointer
   to the io_context of the thread it should post its callbacks to, and
   then post callbacks to those io_contexts when UDP cmd responses