Add visualization tool to debug image sources

[phillebaba]

This change will finally empower users to debug Spegel image pulling without having to grok the logs. Over the last year a common question that I receive is "how do I know if Spegel is working?". The install process works sometimes too well which confuses people. While the logs are dynamic and do not tell the whole story of the behavior.

This PR adds a new disabled by default debug page which which will visualize image pull events that occurred on the node. The event tracking will for now occur in memory, and will only run when the feature is enabled. This tool is not meant to be used to debug after the fact errors. We will start off small and revisit this feature a couple of more times in the future to expand it.

• Track both outgoing and incoming requests
• Filter outgoing and incoming requests
• Filter based on images
• Add handler to metrics server
• Add option to disable visualizer
• Document feature

Fixes #24

[phillebaba]

While it works we need some better tool to visualize than graphviz.

[bittrance]

I looked at event logging yesterday and came up with a similar solution, e.g. not logging HEAD requests and using client IP or peer. The main difference is that in my solution I had:

@@ -181,9 +197,9 @@ func (r *Registry) registryHandler(rw mux.ResponseWriter, req *http.Request) str
        }

        // Request with mirror header are proxied.
-       if req.Header.Get(MirroredHeaderKey) != "true" {
+       if req.Header.Get(MirroredHeaderKey) == "" {
                // Set mirrored header in request to stop infinite loops
-               req.Header.Set(MirroredHeaderKey, "true")
+               req.Header.Set(MirroredHeaderKey, uuid.New().String())
                r.handleMirror(rw, req, ref)
                return "mirror"
        }

The UUID can then be used as the ID in logged events, which will allow connecting events from different spegel peers, effectively working as request tracing.

[phillebaba]

I know that Containerd already adds a traceID to its request headers so if we wanted to use it we could. If someone wants this it is better to add this in a new PR. I just feel like adding more debugging features to the logs is the antithesis of this feature.