feat(insights): ensure all links within domain views, stay within domain views

[DominikB2014]

Work for #77572

This ensures any links within a module that is within a domain view, stays within that domain view.
(this means you can now go to the http domain summary, resource summary, etc)

This is only necessary to support existing insights, and domain view work, at the same time. Something to keep in mind, this is all likely to change at somepoint when we remove the flag and do the release, i was trying to be "non-intrusive" as possible with the existing stuff so it works well in two places

This was quite tricky to do, so to make it support both at the same time, i'm using the pathname rather then query params in order to keep track of what page to render. This is because all modules use subpaths to get to their respective summary pages. This all handled in a new component called ModuleRenderer which looks at the current url to render the appropriate module page/summary page.

There are other approaches to this problem,

1. Create a wrapper component for each module, the wrapper would have all the domain view controls (overview, web vitals, http, assets). The issue I found with this approach, is that it seemed like a lot of duplication. And we'll to handle the case where a module fits under many domain views.

[codecov]

Codecov Report

Attention: Patch coverage is 51.28205% with 19 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
static/app/views/insights/pages/moduleRenderer.tsx	15.38%	11 Missing ⚠️
...ts/browser/resources/views/resourceSummaryPage.tsx	0.00%	5 Missing ⚠️
static/app/views/insights/pages/useFilters.tsx	78.57%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #77804      +/-   ##
==========================================
- Coverage   78.09%   78.08%   -0.01%     
==========================================
  Files        6979     6983       +4     
  Lines      309716   309826     +110     
  Branches    50696    50714      +18     
==========================================
+ Hits       241862   241919      +57     
- Misses      61377    61430      +53     
  Partials     6477     6477              

[DominikB2014]

Todo, fill this in

[0Calories]

This is fine if it's just a temporary change and to help you debug, but I'm not quite following the rationale for having a structure like this. It's understandably more tedious, but in my opinion a much cleaner approach, if we were to stick to the pattern of specifying individual routes.

The approach you have here to automatically determine the URL based on the module is smart, but it's a pattern that isn't followed anywhere else in our codebase and has the potential to be difficult to build upon and restricts us if we need to refactor in the future.

For the sake of organization, we should prioritize separation of concerns rather than minimizing some code duplication. Here's what I suggest:

• Make separate PRs for each new domain landing page
• Use a query param to determine which tab is selected, aka the module to display in the current domain
• Define separate routes for the subpages, like span summary pages for the individual domains
• You can still greatly reduce code duplication by using a pattern like Composition & Specialization. You can use Composition to define the general structure of the domain landing pages and then Specialization to implement the specific structures for each landing page

Following a design pattern for structuring these pages will greatly improve code readability, discovery, and will be easier to build upon or refactor in the future if needed

[DominikB2014]

Closing in favour of another approach