[Meta] NSS Issues

[skhamis]

I wanted to have a meta issue for NSS as there are a few issues across the board and overall it's a pretty complex. The ecosystem has changed quite considerably since it's been used in the repository and felt we needed a central place to track all the NSS problems we either need to fix or document.

Related issues:
#962
#3917
#4828

Two main crates consume NSS:

• it's used in SQLCipher (slowly being phased out)
• it's used in rc_crypto, which is a dep for a lot of our crates

What are the current problems?

1. Cross compiling NSS is very difficult, and thus our build scripts have an additional amount of complexity to needed to support this.
   • Windows has worked intermittently throughout (as it stands right now, it doesn't work)
   • Introductions of M1/aarch build for Macs increase another level of complexity
2. We have to compile it via the guide linked above, and upload it to a S3 bucket, which no one on the current team has access to. While we definitely can request permissions, we should rethink if we need the S3 at all
3. We cannot pull from the NSS TryServer because we have extra options (like static builds vs dynamic) and certain objects/headers we consume that they don't build by default.

Proposed solution:

Remove the cross-compiling of NSS on CI and pulling of the desktop NSS libs from S3

To make this happen we'll need a few things:

• 1. Static builds need to be enabled in the NSS CI - https://phabricator.services.mozilla.com/D162252
• 2. Removal of MinGW support in application-services - Remove support for MinGW on Windows #5238
• 3. Instead of pulling from an S3 bucket, create a TaskCluster task that will indefinitely hold the artifacts of the NSS version we're building against - Update where mac cross compiler fetches precompiled NSS [ci full][ff-android: main][fenix: main] #5254

The benefits we get from the above solution is:

1. Our NSS update process because MUCH simpler

• Also allows us to stay closer to latest patches, also prevents us or someone unfamiliar with the system having to work out the entire build NSS build process if a security patch is needed

4. Makes it much simpler to get both windows and M1 macs as well as any future hardware we may need to support
5. Reduces complexity of our build scripts

So while there may have been a benefit before for cross compiling NSS and having it on S3, the system has evolved to a point where there might not be as much of a gain to cross-compile NSS for android unit testing.

Would love any feedback from anyone who has context on why this solution may not work!

┆Issue is synchronized with this Jira Task

[skhamis]

Turns out the initial proposed solution didn't work (remove having precompiled desktop NSS for android at all) because it turns out it's we need at least Mac artifacts to prevent android testers from having to build & setup NSS locally just to run android unit tests.