Migrate to manifest v3

[jupenur]

Resolves #58.

[jupenur]

This is targeting the #213 branch, that's why you don't see any tests running here. Review and merge #213 first and GitHub will automatically retarget this to main, then the tests should run.

[jupenur]

Rebased

[lsd-cat]

I wonder what's your opinion on keeping the cache in or our the persistent storage? I don't know how often the bg page will actually be terminated, but my impression would be that the cache would lose a lot of utility this way

[jupenur]

The default timeout is only 30 seconds, so I agree we should probably persist the origin cache. Looking into it now.

[jupenur]

OriginState objects are now persisted per session, matching the pre-MV3 behavior. I decided not to explicitly persist nonOrigins because the in-memory set is already populated via a simple storage lookup here:

webcat/extension/src/webcat/db.ts

Lines 72 to 79 in e6dd261

	// 3. Storage lookup
	const stored = await this.enrollments.get(fqdn);
	if (stored) {
	return new Uint8Array(stored);
	} else {
	this.nonOrigins.add(CacheKey(fqdn, cachePartition));
	return new Uint8Array();
	}

[jupenur]

There was some refactoring involved in making the OriginState classes compatible with session storage. Namely, OriginStateHolder is now gone, and there's only one mutable OriginState class instead; the LRUCache API is now asynchronous (and for consistency so is LRUSet) and subclassed into PersistentLRUCache; and the OriginState class implements a toPOJO method that returns a plain JavaScript object that's compatible with the storage API.

[lsd-cat]

This is great, thank you! I've spent some time trying to figure out the implications of using the storage, especially for risks of race conditions (not necessarily security-sensitive, but still). I'm gonna take some more to brainstorm and test more to see if I can spot and test concrete cases

[jupenur]

03364e7 should resolve some of the concerns around race conditions.

[lsd-cat]

Thanks, it's great to see this live! I think it's well structured and will improve mantainability, as it seems already with the lib draft PR. The comments are only about worrying whether adding awaits to code we expect to be sequential actually breaks some guarantees we expected in the past. I'm gonna do some more testing a dig a bit more into real behavior to see if they are plausible, but they are not necessarily blocking. Thanks also for making the cache atomic.

[lsd-cat]

I got a bit in a rabbit hole here. It is my understanding that executions are normally sequential and the extension backend is single thread, so inside the same function we should have some degree of atomicity. However, I'm unsure what the behavior is when we await and if execution is potentially passed to other contexts and then resumed when the await has completed. If that's the case, there's a a potential race here and in similar code patterns. Though it's pretty unlikely, I'd just like to double check if the reasoning holds

[lsd-cat]

This is not specific to this PR, but probably an earlier regression of when we moved out of IndexeDb. If the await/async assumption is correct, then there's a tiny window where the list is empty and an enrolled website could be skipped.