Remove old d3 flamegraph code and d3 dependency.

[aalexand]

Fixes #777.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ec68065) 66.97% compared to head (4d87e8c) 66.83%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #825      +/-   ##
==========================================
- Coverage   66.97%   66.83%   -0.14%     
==========================================
  Files          45       44       -1     
  Lines        9865     9800      -65     
==========================================
- Hits         6607     6550      -57     
+ Misses       2797     2790       -7     
+ Partials      461      460       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ghemawat]

Thanks!

[ghemawat]

Should we perhaps change this to a permanent HTTP redirect to avoid people bookmarking /flamegraph2?

Also, do we want to preserve support for /flamegraphold (either redirect or an alias) to avoid breaking existing bookmarks, links, etc.

[aalexand]

Yes, makes sense, but after spending 10 minutes on this it turned out to be trickier than I thought - http.Redirect("flamegraph") doesn't work since we have this higher level stripping of "/ui" and I assume we don't want to hardcode "/ui" in the redirect path since this defeats the purpose of this prefix being transparent to the implementation. I tried using a relative path in the redirect location but that didn't work either for some reason, need to look into this more. Maybe the StripPrefix() handler need to inspect the response and recognize redirects adding the /ui prefix back, but that means that whoever embeds this server in their server under a custom prefix will have to do the same and meanwhile the redirects will be broken for them. I might be missing a trivial solution? Anyway, will need to look more into this.

[ghemawat]

Can we get the current request's URL and replace a trailing /flamegraph2 with /flamegraph to form the new URL?

[aalexand]

As far as I can tell, StripPrefix() modifies the request URL destructively.

[ghemawat]

If I understand correctly, /foo redirects to /ui/foo. Then /ui/foo is handled by stripping the /ui prefix and then looking up the handler in the handler map.

What if we drop the StripPrefix call and have the handler map keys start with /ui? But perhaps some clients are doing something weirder?

Alternative: instead of calling http.StripPrefix, we provide our own wrapper that first examines the original URL and either (a) redirects from flamegraph2 to flamegraph, or (b) returns the precomputed http.StripPrefix() result.

[aalexand]

I ended up using a small bit of code to return a relative path redirect instead of using http.Redirect() which does not support that. This is similar to this code in Go runtime itself so I think this is reasonable.

[ghemawat]

Looks great!