Add Send + Sync bounds to resolve Arc clippy warnings

[seanybaggins]

• Add Send + Sync bounds to LogProvider trait
• Add Send + Sync bounds to ExpiryPolicy trait
• Add Send + Sync bounds to action traits: MetaAction, StaticAction, StatefulAction, HairpinAction, ActionDesc
• Add Send + Sync bounds to SNAT implementation trait bounds
• Add unsafe Send + Sync implementations for KStatNamed

Fixes #785: Port should require Send + Sync bounds

This minimal implementation only adds bounds where compilation errors occurred, ensuring Arc<Port> and Arc are Send + Sync.

Before

 cargo clippy
    Checking opte v0.1.0 (/home/sean/personal-repos/opte/lib/opte)
    Checking oxide-vpc v0.1.0 (/home/sean/personal-repos/opte/lib/oxide-vpc)
    Checking xde v0.1.0 (/home/sean/personal-repos/opte/xde)
warning: usage of an `Arc` that is not `Send` and `Sync`
   --> xde/src/xde.rs:403:20
    |
403 |         let ectx = Arc::new(ExecCtx { log: Box::new(opte::KernelLog {}) });
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `Arc<ExecCtx>` is not `Send` and `Sync` as `ExecCtx` is neither `Send` nor `Sync`
    = help: if the `Arc` will not be used across threads replace it with an `Rc`
    = help: otherwise make `ExecCtx` `Send` and `Sync` or consider a wrapper type such as `Mutex`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#arc_with_non_send_sync
    = note: `#[warn(clippy::arc_with_non_send_sync)]` on by default

warning: usage of an `Arc` that is not `Send` and `Sync`
    --> xde/src/xde.rs:2371:8
     |
2371 |     Ok(Arc::new(pb.create(net, limit, limit)?))
     |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: `Arc<Port<VpcNetwork>>` is not `Send` and `Sync` as `Port<VpcNetwork>` is neither `Send` nor `Sync`
     = help: if the `Arc` will not be used across threads replace it with an `Rc`
     = help: otherwise make `Port<VpcNetwork>` `Send` and `Sync` or consider a wrapper type such as `Mutex`
     = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#arc_with_non_send_sync

warning: `xde` (lib) generated 2 warnings
    Finished `dev` profile [optimized + debuginfo] target(s) in 5.83s

After

cargo clippy
    Checking opte v0.1.0 (/home/sean/personal-repos/opte/lib/opte)
    Checking oxide-vpc v0.1.0 (/home/sean/personal-repos/opte/lib/oxide-vpc)
    Checking xde v0.1.0 (/home/sean/personal-repos/opte/xde)
    Finished `dev` profile [optimized + debuginfo] target(s) in 5.53s

Disclosure

I did use claud-code to assist with this.
Added this function

   fn assert_send_sync<T: Send + Sync>() {}
   assert_send_sync::<Port<crate::engine::NetworkImpl>>();

To identify where Send, Sync needed to be added. Then asked a lot of questions and poked around the code trying to determine safety of

#[cfg(all(not(feature = "std"), not(test)))]
unsafe impl<T: KStatProvider> Send for KStatNamed<T> {}
#[cfg(all(not(feature = "std"), not(test)))]
unsafe impl<T: KStatProvider> Sync for KStatNamed<T> {}

[FelixMcFelix]

Thanks for this, and sorry for the delay in getting back to you. Send/Sync reasoning need close thought, hopefully these comments are helpful.

[FelixMcFelix]

I think that, currently, this bound is far too broad (i.e., if T is not Send or Sync, neither should KStatNamed be). I believe the correct narrowing might be that we impose, higher in this file, that pub trait KStatProvider: Send + Sync, since the data associated with each kstat will need to be accessed in at least one other kernel thread if there's a kstat invocation.

[FelixMcFelix]

I think this can be more concisely summarised, after applying the other suggested change, as a statement that:

• The underlying T must itself be Send + Sync because it is fully visible to any user of the struct. We meet this through the new type bound on KStatProvider.
• ksp is itself safe to move between threads, since KSTAT(9S) imposes no MT constraints on callers.
• ksp is never exposed via a &ref (nor is it used by any methods taking &self), and is only used during drop as you point out above.