Setup tracing-flame for use profiling zebrad

[yaahc]

part of ZcashFoundation/zfnd#60

[dconnolly]

lgtm!

[teor2345]

Thanks for getting this working!

Have you tested it?
I'm not sure if it will work on all platforms, or on all future compiler versions.

[yaahc]

I have really strong reservations about the platform-specific code that adds special behavior for Windows and Kubernetes. This is the first platform-specific code we have in the project, and from reading the PR I'm not sure exactly what we get from adding it. On the downside, now we have Windows-specific interrupt handling code -- have we tested that it works? Can we test it on an ongoing basis without having to write platform-specific interrupt testing code?

From the code it looks like the purpose is just to allow Ctrl-C to emulate SIGTERM while developing. But it seems like we could also achieve that purpose without adding any code to Zebra using killall -SIGTERM. Is there another purpose that I'm missing?

@hdevalence the initial implementation didn't have any plaform specific code and just relied entirely on tokio::signal::ctrl_c. I figure that API is probably reliable enough where we don't need to do our own windows testing to prove that it works. I added the platform specific handling based on @teor2345's feedback here #436 (comment)

I don't think switching to only handling SIGTERM is a viable solution. There is no sigterm on windows and I think this would be a huge usability regression vs handling ctrl-c, which is how I'd like to be able to terminate the application when working with it day to day. With signals there's a limit to how much we can abstract the behaviour independent of platforms given that windows and linux handle signals and termination of applications completely differently AFAIK. With tokio::signal::ctrl_c that platform specific handling is just in a dependency instead of in our code, and we don't get SIGTERM handling which is likely quite valuable as noted by teor. I think the current implementation is likely reasonably reliable, given that it is vendored from linkerd, and if the ctrl-c handling on windows is broken I don't see that as a huge risk, given that this will just leave us in the same situation we're already in currently where there's no way to gracefully shut down zebrad on windows.

[teor2345]

Looks great!

I'd like us to document the new exit codes, but otherwise I think we're fine here.

[teor2345]

I'm not asking for an implementation change here. I don't think having specific return codes for each signal is useful or important for zebrad.

But these new return codes should be documented somewhere in the book.

Let's also document that unhandled signals still use the default return codes.

[teor2345]

I think the default log level has to be "warn", for commands that use standard output.

Otherwise looks good.

comment was a non issue

[teor2345]

Looks good, just one doc tweak, then I think we're done.

[hdevalence]

I don't think that the structure of the tracing setup code is very good but as noted in this comment #436 (comment) I think that this awkwardness is forced by our previous decision to upstream our tracing component, which we now have no control over. I would like to try to fix this and "componentize" many of the other parts we currently construct ad-hoc in a later PR.

I still have concerns about the platform-specific behavior but I don't want to block this PR on it.