WIP: Allow re-symbolication to use the WebChannel, take 2

[mstange]

This PR supersedes #3504 and passes tests. However, the implementation is rather ugly. The browserConnection prop needs to be passed all the way down the following chain: <Root> -> <AppViewRouter> -> (<ZipFileViewer> ->) <ProfileViewer> -> <MenuButtons> -> <MetaInfoPanel>.

I'd love to hear suggestions for alternative approaches! I've considered the following:

• Passing down a callback prop for the button click handler instead, e.g. onResymbolicateButtonClick.
• Making more use of React children props, e.g.:

<ZipFileViewer>
  <ProfileViewer infoPanel={
    <MetaInfoPanel browserConnection={...} />
  }>
</ZipFileViewer>

• A global variable for the browserConnectionStatus. But global variables make tests really annoying, I'd like to avoid them if at all possible. We currently are in the global variable situation with window.geckoProfilerPromise and it is very annoying to deal with.
• React Context. I'm not sure this would actually solve the problem - you'd still need to pass down the context object that's returned by the call to React.createContext(), or put it in a global. It would make the testing situation easier, though. I also don't know how it interacts with connected components.
• Putting the browserConnection in the redux state. I didn't really consider this because it's very strange to store something in the state that you call methods on. The state should be more like a plain-old-data object.

---

This PR makes the following workflow work:

1. Capture a profile in local build A but save it without symbolicating, e.g. as a shutdown profile.
2. Import the file into the profiler in Firefox build B, which cannot fully symbolicate it.
3. Upload the profile in build B. Example result: https://share.firefox.dev/37WzwZF
4. Load the public profile in build A.
5. Re-symbolicate in build A. Example result: https://share.firefox.dev/3z4Agb1

┆Issue is synchronized with this Jira Task

[codecov]

Codecov Report

Merging #3656 (5b13540) into main (10157bd) will decrease coverage by 0.04%.
The diff coverage is 77.86%.

@@            Coverage Diff             @@
##             main    #3656      +/-   ##
==========================================
- Coverage   88.90%   88.86%   -0.05%     
==========================================
  Files         258      259       +1     
  Lines       21498    21581      +83     
  Branches     5494     5519      +25     
==========================================
+ Hits        19112    19177      +65     
- Misses       2212     2229      +17     
- Partials      174      175       +1     

Impacted Files	Coverage Δ
src/components/app/Home.js	67.74% <25.00%> (-4.03%)	⬇️
src/test/fixtures/mocks/browser-connection.js	28.57% <28.57%> (ø)
src/actions/receive-profile.js	86.25% <66.66%> (-0.05%)	⬇️
src/test/fixtures/mocks/web-channel.js	86.90% <85.00%> (-7.39%)	⬇️
src/components/app/AppViewRouter.js	80.00% <87.50%> (ø)
src/components/app/Root.js	90.90% <87.50%> (-9.10%)	⬇️
src/actions/app.js	88.29% <100.00%> (ø)
src/components/app/DragAndDrop.js	98.48% <100.00%> (+0.02%)	⬆️
src/components/app/MenuButtons/MetaInfo.js	85.71% <100.00%> (+0.57%)	⬆️
src/components/app/MenuButtons/index.js	88.17% <100.00%> (ø)
... and 7 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 10157bd...5b13540. Read the comment docs.

[mstange]

• Putting the browserConnection in the redux state. I didn't really consider this because it's very strange to store something in the state that you call methods on. The state should be more like a plain-old-data object.

I gave this more thought and I think this might actually be the way to go. I can't think of any trouble it could cause. It would definitely solve the problem: Connected Components can simply grab the browserConnection(Status) object from the redux state and short-circuit the downwards property propagation; it's what they're designed to do.