Rewrite HTTPS Everywhere parser in Rust

[fmarier]

The EFF has started to rewrite the HTTPS Everywhere parser in Rust and cross-compiling it to WebAssembly to reduce memory overhead (they saw a reduction of 20MB for each running instance).

The two LGPL-licensed libraries are:

• libcore (intended to work cross-platform)
• libwasm (wrappers for libcore)

(The extension pulls in libwasm, which pulls in libcore.)

libwasm contains:

• basic structs for cookie rules and rulesets
• potentially_applicable() which returns matching rules given a URL

We might be able to make use of some of this code to replace our C++ parser, though that would also mean downloading the ruleset in JSON instead of the binary .dat file we currently generate in https://github.com/brave/https-everywhere-builder.

[antonok-edm]

I am working on this now. cc @pes

It would be necessary to move to the same JSON ruleset format used by the EFF. There should be some kind of migration strategy in place to deprecate the current LevelDB format. Perhaps shipping both formats side-by-side for some number of releases.

The current HTTPSE implementation in Brave uses MRU caching by domain, which is not present in the EFF library. This could be kept in-place to reduce the number of calls to the Rust library, but it's worth benchmarking to understand the performance implications either way.

The EFF library also supports Secure cookie rewriting and EASE (Encrypt All Sites Eligible), which are not currently implemented in Brave. Migrating will make both of these features easier to implement and support.

[pipboy96]

@antonok-edm @fmarier What's the current status of this issue? Can I help in any way?

[antonok-edm]

@pipboy96 I have a working build based on EFForg/https-everywhere-lib-core#2 (currently in this branch). Was planning to push the C++ FFI repo I made to the Brave org once I'm depending on an upstream version.

[antonok-edm]

Currently blocked by #7316. We currently use a custom LevelDB format to load HTTPS Everywhere rules, it would be useful to support the upstream JSON format but the migration will require version-locked extension data.