Fix signals handling to allow graceful applications' shutdown

[neslinesli93]

When using this library within an actix 4 application, we face the following issue: actix/actix-web#2638

Basically if the application has the actix_web::main macro in the entrypoint, it's not able to handle signals to shutdown gracefully. The hack to solve this is to replace the former macro with tokio::main.

However this issue has been resolved in the opentelemetry repo, where the maintainers suggested to replace opentelemetry::runtime::Tokio with opentelemetry::runtime::TokioCurrentThread when initializing the tracer. I've done a couple tests locally and it seems to work exactly the same, either when tracing is initialized within an actix web context, as well as when it's initialized inside a pure tokio context.

I please ask you to review the change carefully because I don't have any deep knowledge with tokio, nor opentelemetry stuff (or rust at all :D)

[miterst]

Maybe we can gate it under a feature so it can work with both actix-web::main(single-threaded) and tokio::main(can be both single/multi threaded)?
Default can be as it's now, and we can add the rt-tokio-current-thread feature.
An example of how opentelemetry-jaeger does it.

[neslinesli93]

It makes a lot of sense! I still have doubts on why during my tests I managed to make it work with both actix_web and tokio main macro... Probably I didn't know how to make it fail :D

[miterst]

Actually opentelemetry::runtime::TokioCurrentThread would work with both just that its better to make use of the underlying multi-threaded runtime in case we already have it.

[neslinesli93]

At this point, maybe it would be better to pass some kind of option to prima_tracing.rs so that it chooses what kind of strategy to use, instead of a crate feature?

[miterst]

Ah sorry my answer above doesn't seem fully right.
I saw that opentelemetry::runtime::TokioCurrentThread does std::thread::spawn so if you use it with the tokio multi-threaded runtime you may end up with both tasks spawned on the same thread and have the same problem.
So in this case it may be better to follow the approach of other similar libraries that expose these options with features.

[neslinesli93]

Closing for staleness, we'll be using tokio::main and forget about signals :)