backtracing docs in Swift Server guides

[heckj]

backtrace documentation

Summary

• adds references on how to enable backtrace collection for static and non-static builds
• adds swift backtrace reference content, built from swift's docs/Backtracing.rst docs
• adds an article on how to debug using a backtrace
• provides reference content based on an example (test failure for the backtracing, including content from a Swift linux build and crash)
• adds detail about how to build and capture debugging details in a binary as a "side-car" alongside a production binary built in release mode
• adds debugging flows for how to investigate when you can't find an expected backtrace after a service crash

resolves #87

Validation

• swift package generate-documentation --analyze --warnings-as-errors passes
• Previewed locally with swift package --disable-sandbox preview-documentation

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[al45tair]

We might want to hold off on this section; we've been working on a tool that can symbolicate the output from the backtracer automatically — we're just waiting for a new repository to be created under swiftlang then we can push the code and organise a blog post about it.

With the new tool, you can just feed your log file to swift-symbolicate and it will output the same log file but with any crash reports it finds within symbolicated — it also knows how to fetch debug symbols from debuginfod or Microsoft-style symbol servers, and additionally can be used to convert between JSON and human readable output formats.

The new tool also keeps any data in the output that isn't a Swift crash log, so you can just feed a raw copy of your stdout/stderr to it and you'll still have all the other output from your program.

[heckj]

wow - nice! That sounds fantastic!

I'd prefer to include all the details now about how to get to what you critically need to debug your app, but then shift/update this content when that tool is available to reference it preferentially. Holding off on docs because we're going to be getting to it has led us into some traps in the past where timelines just didn't agree with our intentions, and I'd prefer to err on the side of having useful information in a developer's hands.