Remove innerWindowID from the frameTable once the active tab view is gone

[mstange]

The frameTable has an innerWindowID column so that we can determine, per sample, whether that sample was relevant for a given page. This is what we use in the active tab view to hide samples from other tabs.

But the active tab view is going to be removed (#4997).

The replacement doesn't do any filtering of samples. The motivation for this was two-fold:

1. Firefox Desktop now puts separate origins into separate content processes ("Fission"), so by filtering processes, you also make sure that the remaining processes only contain relevant samples.
2. Even if code from different pages runs in the same process, anything within a process can be relevant to slow performance, so it's better to just show it all.

This means that the innerWindowID information in the frameTable will be unnecessary. We will need another way to know which process is relevant to which page (#5442), but with that fixed, we should just remove the innerWindowID column from the frameTable entirely.

┆Issue is synchronized with this Jira Task

[canova]

I'm removing the active tab view in #5483 but I didn't remove frameTable.innerWindowID yet. It's mostly because there are still a few places that use it. The first thing I saw is that still the sanitization logic uses it for detecting the markers that are coming from private browsing tabs.

It appears that each thread that comes from private browsing already has isPrivateBrowsing flag set: https://github.com/firefox-devtools/profiler/blob/657962beb625793a9a9f2d84a04d3502df082989/src/types/profile.js#L668-L673

But it only works when fission is enabled. I believe this use case was added mainly for Firefox Android. And I think fission is still not completely shipped in Fenix (correct me if I'm wrong)? So I believe this is still an open question on how to sanitize these things.

[canova]

Hm, also if we remove this field we are going to lose this section in the frame tooltips:

Even though we still have the origin information from the track, and we can see the file itself, being able to see which page it comes from has been sometimes useful to me (for attributing to the correct page in the cases where there could be 2 pages in the profile from the same origin).

Do you think this is important? Or can be deducted from other places?

[mstange]

Hmm, I see, that does seem somewhat useful.

Then maybe we should instead try to make the column optional and/or more compact. For example we could store an IndexIntoPageList in the places where we currently store an InnerWindowID; that takes fewer digits in the JSON and can probably use an Int16Array instead of a Float64Array in the call node table.