Added KillableExecutor

[cryptographix]

KillableExecutor, as its name suggests, is an arch-std Executor that can be cleanly killed. The main noticeable difference is that the init closure passed to run() has a second parameter of type Killer, which wraps a Signaler (so as to be Copy and Clone). This killer is checked during the Executor's polling loop, and when signalled, causes the Executor to exit.

Rationale: Although it makes little sense to terminate a device-based Executor, arch-std is running on a conventional OS, and thus there are use-cases where it makes sense to terminate. Specifically, when testing 'embassy'-based code on std-arch with h/w mocks, having a way to terminate the Executor allows a test_harnessto be created such that #[test] and cargo test can be used. Example:

#[test]
fn test_clock() {
  test_harness(|spawner, killer| {
    // this is the task under test
    spawner.spawn(clock_task()).unwrap();

    // and here is the test-code, running as a separate task.
    spawner.spawn(clock_test_task(spawner, killer)).unwrap();
  });
}

In the example, the #task-under-test# clock_task is first spawned, followed by a separate test task clock_test_task which receives the killer object and signals the Executor to shut down once the tests have finished. In this way, cargo test continues and runs the next #[test].

Example test_harness:

pub fn test_harness<F: FnOnce(Spawner, Killer)>(fun: F) {
  static EXECUTOR: StaticCell<KillableExecutor> = StaticCell::new();
  let executor = EXECUTOR.init(KillableExecutor::new());

  // Setup logging
  env_logger::builder()
    .filter_level(log::LevelFilter::Info)
    .format_timestamp(None)
    .format_target(false)
    .init();

  // and run the test
  executor.run(fun);
}

I'm pretty sure there's some cleanup missing .. and I'm not yet certain what happens if a test panics, but I'm submitting this initial PR as a way to solicit comments from the more knowledgeable, as to whether this is viable.

[Gerharddc]

How about a simpler approach doing this with an AtomicBool such as Gerharddc@d7b1f33 perhaps?

[Gerharddc]

@cryptographix it seems #5047 has now been merged as an alternative solution. does this work for your use case?

[cryptographix]

@cryptographix it seems #5047 has now been merged as an alternative solution. does this work for your use case?

Yes. Thank you! Simpler solution, love it.