feat(Tag Tracking+): Reduce API load when multiple Tumblr tabs are open

[marcustyphoon]

Description

I think this is my first version of #1813 that I'm not aware of any bugs in.

This is a full(?) version of what I hoped to do to Tag Tracking+: an implementation which:

• does not perform more API fetches with many tabs open than with one tab open
• does not perform more API fetches when opening/refreshing many tabs than when opening/refreshing one tab
• does not perform as many API fetches if you open a tab, close it, open a new tab, close it, etc. as previously
• does not meaningfully change the user experience
• improves edge case behavior (repeatedly disabling/enabling the feature, only tracking one tag)

General description of the implementation:

• Unread counts are stored in storage, along with their last-updated timestamps, which is a single source of truth for every tab (besides the dom). A count never goes back to ... and a sidebar never goes back to data-loaded=false; besides this, all tabs' sidebars are rendered using the same data (updateSidebar depends only on storage and is called only in onStorageChanged).
• As the storage is a cache—any entries older than 30 seconds are wiped on feature enable—I had the idea that we could exclude the storage entry from the backup tab export, but we of course don't have to do this. (Every tag tracked by any user that's been logged in with the feature enabled on the installation is already in there; we're adding basically no additional data to the export.)
• Only one tab may refresh at a time (per tracked tag list)*, implemented by each tab keeping a timestamp of when any other tab has refreshed and declining to refresh unless it's been longer than the desired interval (i.e. the actively refreshing tab must have been closed). This isn't 100% robust (closed-tab race condition chance; waking a computer from sleep), but it should fix itself quickly.
• Refresh behavior is also dependent entirely on storage contents (checked in real time), so it doesn't matter which tab does the refresh.
  • A new tab marks all of its tracked tags as "needs initial load" in main; if any tags need initial load, they're loaded in order by the refreshing tab at up to 2/sec.
  • If no tags need initial load, tracked tags are refreshed in least-up-to-date order at an arbitrary rate until (with few enough tracked tags) they're all fresher than an arbitrary ttl. (Not sure what we want to set these numbers to, but I think it makes sense to have both of them.)
• Stopping the refresh loop is rewritten so that it actually stops immediately (idk what to call the technique honestly).
• On initial load—i.e. when hard navigating to tumblr, refreshing the page, or enabling the feature—storage contents are wiped unless they're quite recent (30 seconds). This means all or a significant chunk of an initial load can be reused if you f5 during it, open a new tab during it, etc, but f5 still means "fetch new counts, please."
• In a separate commit, because maybe this is getting too cute: when in show-all-counts mode, even though fresh cached counts are used during initial load instead of fetching, a "loaded" boolean field is used to make them not appear in the sidebar immediately (which looks kind of strange if they're preceded by some non-cached tags); instead, they become "loaded" and visible when they would otherwise have been fetched, preserving the "waterfall" sequential load sequence. Yes, this means the caching doesn't meaningfully reduce the load time in show-all-counts mode if you keep this commit.

*Not tested, but I think conceptually the e.g. "six Firefox container tabs logged into three accounts with different tracked tag lists" scenario should work correctly (at up to 3x API load vs a single tab, depending on tracked tag count and overlap). Tabs with the same tracked tag list should elect a single tab that's allowed to refresh.

Note: I don't love the errored-tag behavior here, but I'm not sure what the ideal behavior actually is. The main problem when deciding that is that in practice the main way I see the ⚠️ appear is when interrupting a fetch by closing a tab/putting the computer to sleep/disconnecting from the internet (probably shouldn't sync that to other tabs at all, and if one does, the tab should probably immediately retry the errored tag), but that doesn't necessarily demand the same behavior as "something is wrong with fetching this tag specifically" (in which case one should probably only reattempt it as part of the cycle... or at minimum shouldn't spam attempts every half a second at the expense of all other tags).

Draft because of that, because console.info() calls are not removed currently, and because maybe I can still think of a solution with fewer lines of code.

edit: Oh, and reminder to myself to consider using document.hasFocus() in some way. Also, potentially always run a 500ms loop and do nothing if the count mod 60 (or whatever) isn't zero in background-refresh mode, as this is more flexible.

Screenshots

n/a (I could take a video of side by side tabs with devtools open, I suppose, but that would be a lot of work)

Testing steps

tba

[marcustyphoon]

master...AprilSylph:XKit-Rewritten:marcustyphoon/tag-tracking-deduplicate-storage-dev-13 Hm, maybe pure-storage is actually better?

edit: Aw. I briefly got excited that even without a background script, we could use session storage in content scripts on a progressive enhancement basis by calling browser.storage.session.setAccessLevel({ accessLevel: 'TRUSTED_AND_UNTRUSTED_CONTEXTS' }); in the extension popup. I hadn't realized that that's completely unimplemented in Firefox.