Update handling of similarly named extensions

[autumnfound]

As the Open VSX registry grows, malicious actors increasingly attempt to distribute malware through "typosquatting" and direct spoofing of popular extensions. To protect end-users and maintain platform trust, we are introducing strict validation mechanisms to prohibit duplicate extension names. This includes database-level constraints on unique identifiers and an intelligent pre-publication check that quarantines new extensions attempting to hijack the "Display Name" of highly popular, established tools.

Currently, we have a SimilarityCheckService built into the project that does fuzzy matching on all extension names and has a configurable distance for fuzziness that allows for tweaking of the sensitivity of the matching. This mechanism is part of the pre-publication checks that already exist and fulfil most of the requirements of the request to handle these maliciously named extensions.

Of the features remaining, we want to ensure that we have a way to easily distinguish the number of attempted spoofed extensions, a way to action them, and potentially an admin override of blocked terms. We will also want to ensure that the check is enabled and sufficiently strict.

some issue details repurposed from internal request

[autumnfound]

Additionally, we will want to add a check to the extension publish check that ensures that the combination of <namespace>.<extensionName> has not already been used to reduce potential spam. As low-hanging fruit, I can add the above feature as an easy win.

With regards to the handling of spoofed extensions, as this is already a publish check that is already implicitly handled by the admin scan decision dashboard. For retrieving this data, I'm fiddling with my local instance to see if we can filter the scans to those failed with typo squatting, and I believe it can, though I'd want confirmation before I say that feature can be effectively done with the current dashboard. Once we have the soft deletion code finished, it should be able to effectively block those as well. @gnugomez as someone who has been maintaining the admin dashboard lately, can you confirm?

The only real thing to check is how we want to handle the checking of extension names. Right now it checks the whole data set for matches that are too close for display names and extension names. Do we want to reduce scope to update the check to use a subset of all extension names, and do we want to support custom added/excluded display names to match against?

[autumnfound]

Additionally, we will want to add a check to the extension publish check that ensures that the combination of . has not already been used to reduce potential spam. As low-hanging fruit, I can add the above feature as an easy win.

Digging into the code and testing, this already exists via a unique index on the extension table. No code will need to be written for this!

[autumnfound]

I've talked with Jordi, and it looks like the filter only has scanner types and not publish checks. I think it would be worth adding the publish checks as optional filters to give the admin scan dashboard more flexibility.