Bugzilla

So I think the way this is going to go is:
- Straightforward "tracing" logging with idiomatic spans and events.
  - We'll just log the graphviz "dot" representation of the pipeline as a field.  It can be made conditional on some kind of flag in the future if it turns out to be expensive.  (We might be able to get laziness for free if we have the "dot" diagram be the debug rep so if there's no subscriber the debug formatter won't be called.)
- We'll accumulate the log using the standard "tracing_subscriber" "fmt" JSON subscriber within a [with_default](https://docs.rs/tracing/0.1.32/tracing/subscriber/fn.with_default.html) call.
- We throw the JSON blob at https://crates.io/crates/liquid templating and maybe we give it some custom filters/tags/blocks and it outputs our markdown.  It could probably also 
  - While thinking about the various options for handling more complicated HTML presentation issues like presenting object (field) layouts (ex: [nsINode](https://clicky.visophyte.org/files/screenshots/20200331-021603.png), [mozilla::dom::Element](https://clicky.visophyte.org/files/screenshots/20200331-021616.png)) it seemed like we might do well to adopt a templating language that we can both run on the server and locally on the client.
    - My motivation was primarily about making it easier to get test coverage for UI related features like "what will a contextmenu show for this symbol on this line" without involving webdriver.  If we used a (powerful) templating language that could be shared between the client and searchfox-tool, that would make things easy.  In the end, I don't think the menu use-case makes sense (and in fact we had moved away from a nunjucks generated template in the front-end that had come from DXR), but it does look like liquid is probably the right templating solution for when we need templating.
    - In particular, I think liquid's inclusion of control flow mechanisms would be helpful as opposed to handlebars' approach, which is the other rust templating engine that also has a JS implementation available.
    - I have no underlying desire to change any of our HTML generation to using liquid.  It's not something I'd rule out, but my thinking is that liquid is more of an alternative than adopting something like https://lit.dev/ and having a bunch of JS and web components running in the front-end.  Despite, or perhaps because of, the massive searchfox fancy branch react-based prototype, I'm very much a fan of the current small vanilla JS codebase and how (pre)cache-able server rending can help us keep latencies low and allow the HTML parser to do much of its work off the main thread.

So I think the way this is going to go is:
- Straightforward "tracing" logging with idiomatic spans and events.
  - We'll just log the graphviz "dot" representation of the pipeline as a field.  It can be made conditional on some kind of flag in the future if it turns out to be expensive.  (We might be able to get laziness for free if we have the "dot" diagram be the debug rep so if there's no subscriber the debug formatter won't be called.)
- We'll accumulate the log using the standard "tracing_subscriber" "fmt" JSON subscriber within a [with_default](https://docs.rs/tracing/0.1.32/tracing/subscriber/fn.with_default.html) call.
- We throw the JSON blob at https://crates.io/crates/liquid templating and maybe we give it some custom filters/tags/blocks and it outputs our markdown.
  - While thinking about the various options for handling more complicated HTML presentation issues like presenting object (field) layouts (ex: [nsINode](https://clicky.visophyte.org/files/screenshots/20200331-021603.png), [mozilla::dom::Element](https://clicky.visophyte.org/files/screenshots/20200331-021616.png)) it seemed like we might do well to adopt a templating language that we can both run on the server and locally on the client.
    - My motivation was primarily about making it easier to get test coverage for UI related features like "what will a contextmenu show for this symbol on this line" without involving webdriver.  If we used a (powerful) templating language that could be shared between the client and searchfox-tool, that would make things easy.  In the end, I don't think the menu use-case makes sense (and in fact we had moved away from a nunjucks generated template in the front-end that had come from DXR), but it does look like liquid is probably the right templating solution for when we need templating.
    - In particular, I think liquid's inclusion of control flow mechanisms would be helpful as opposed to handlebars' approach, which is the other rust templating engine that also has a JS implementation available.
    - I have no underlying desire to change any of our HTML generation to using liquid.  It's not something I'd rule out, but my thinking is that liquid is more of an alternative than adopting something like https://lit.dev/ and having a bunch of JS and web components running in the front-end.  Despite, or perhaps because of, the massive searchfox fancy branch react-based prototype, I'm very much a fan of the current small vanilla JS codebase and how (pre)cache-able server rending can help us keep latencies low and allow the HTML parser to do much of its work off the main thread.