Handle SIGTERM and singals from userland

[rustworthy]

As per #4

The development branch is the clone of the feat/async-support. The latter is in my fork of the repo and is destined for main in #49. I will now start creating feature branches in the main repo.

This PR is also adding:

• tracing dep and and a couple of events (heartbeat at trace level, sigterm at info level);
• examples;

---

This change is 

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 93.75000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 69.5%. Comparing base (5c0ff09) to head (6eb5b17).

Additional details and impacted files

Files	Coverage Δ
src/worker/health.rs	88.6% <ø> (+11.3%)	:arrow_up:
src/worker/builder.rs	98.9% <95.2%> (-1.1%)	:arrow_down:
src/worker/mod.rs	83.3% <97.1%> (+2.1%)	:arrow_up:
src/worker/stop.rs	75.0% <75.0%> (ø)

... and 3 files with indirect coverage changes

[jonhoo]

just fyi, I've seen this, but am holding off on reviewing until we get #49 over the finish line.

[jonhoo]

I'd prefer that we don't put signal handling directly into this library, and instead do something like what axum does and allow the user to supply a shutdown future.

[jonhoo]

Also, would you mind doing the examples and tracing in a separate PR just to make it easier to review and land this piecemeal?

[rustworthy]

Also, would you mind doing the examples and tracing in a separate PR just to make it easier to review and land this piecemeal?

Sure. It's not that I like mixing unrelated stuff one PR, rather the example and tracing became a side-effect of adding a signal handling logic, namely testing ctrl c handling

[rustworthy]

Sorry it took me a while (again) 😅

No worries, it actually takes me that exact Duration to iterate over the things

[rustworthy]

@jonhoo Please have another look.

As for the conflicts, #68 should unblock the pipeline in main

[jonhoo]

Just FYI — I'm away on holiday this week, so won't get to this until the weekend after next probably 😅

[rustworthy]

Just FYI — I'm away on holiday this week, so won't get to this until the weekend after next probably 😅

I wish you a great holiday! As for the PRs, I still need some extra time for the tech debt one, so this is actually great.

[rustworthy]

@jonhoo Sorry for pushing amid review request - just pulled the latest from main resolving some minor conflicts

[rustworthy]

@jonhoo I think all the threads have been addressed.

I thing that I have just realized is that we do not allow to Worker::run a terminated worker, and we drop the processing workers we have spawned, but Worker::run_one is still possible since the coordinating worker is not dropped.

Imagine the situation where the server told us to stop the consumption (we get this message in the heartbeat task on the coordinator), and we do so and mark the coordinator as terminated. What they can do then is take this worker and call run_one in a loop mimicking this way the Worker::run logic, but without HEARTBEATing and - most importantly - breaking the server instruction we've received previously. I think this is not something we want to be possible, wdyt?