LIT-2841 - Remove ipfs-http-client and create encryption APIs for composition with any storage layer

[MaximusHaximus]

Description

Overview

This PR removes a problematic dependency that also happened to be very large code and dependency-wise - ipfs-http-client. We were using this in a single place in our SDK as part of a 'nice-to-have' function. Unfortunately, the package has issues with bundling in multiple environments and brings a very large # of dependencies into our bundle that a lot of our users never actually needed.

The API for the method that used this dependency was also problematic; it was hard-coded to use Infura credentials and endpoints, and Infura has disabled the ability to create IPFS-enabled API keys since November of 2023. Rather than re-work the API to allow arbitrary providers, authentication, etc, we decided that it would be more flexible for consumers, and better for the size of our bundles and compatibility in multiple environments, to remove the dependency and instead provide some functions that are un-opinionated about where the encrypted data is going or coming from.

Anyone who would like to encrypt to/from IPFS can simply call these new methods and then use the client of their choice to put the data in IPFS.

Even better, anyone who wants to encrypt/decrypt somewhere other than IPFS, but without compressing the data using our existing APIs that encrypt into ZIP files with metadata stored inside the ZIP archive can use these same methods to work with any other arbitrary data store they want to use.

Before this change, the only code that would wrap up the encrypted data with the metadata required to easily decrypt it later was the 'encryptToIpfs()' code which stored the encrypted data and metadata in the same JSON blob, always on IPFS, or encryptFileAndZipWithMetadata() code which stored the metadata as a separate file from the encrypted data in the ZIP archive and only worked with files (not bare strings).

Changes:

• Removed encryptToIpfs() and decryptFromIpfs() methods in encryption, which were also exported from lit-node-client
• Added encryptToJson() and decryptFromJson() in encryption, and export those methods from lit-node-client
  • These methods produce and consume JSON blobs in the same format as the previous encryptToIpfs() and decryptFromIpfs() methods produced and consumed.

Fixes:

• Resolved an incorrectly applied polyfill for fetch, where we were mutating global fetch even if it was previously defined.
  • We now use cross-fetch to handle this polyfill, which is friendly to environments where it is already defined -- and was already part of our dependency tree due to other dependencies we already rely on.
  • Removed node-fetch direct dependency now that cross-fetch is being used to polyfill.
• Removed ipfs-htttp-client dependency, which was causing bundling errors in mixed environments (NextJS)

Internal changes:

• Removed build tooling hooks for post-build mutations that were we were not running and no longer used
• Cleaned up some duplication in types touching access control conditions
• Fixed a bunch of eslint/tslint errors in the files where changes were made

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Added tests for encrypting/decrypting from JSON strings using both file input and string input
• Ran entire E2E suite

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[MaximusHaximus]

@joshLong145 I went ahead and made the connect() logging in the contracts SDK less spammy like we talked about -- the contents of abi were just arrays of numbers, so I create a map of contract name->address that looks like this:

resolved contract addresses for:  cayenne {
  StakingBalances: '0x095251de2aD2A78aDe96F2a11F7feAA7CF93e6B5',
  Staking: '0x5bFa704aF947b3b0f966e4248DED7bfa6edeF952',
  Multisender: '0xD4e3D27d21D6D6d596b6524610C486F8A9c70958',
  LITToken: '0x53695556f8a1a064EdFf91767f15652BbfaFaD04',
  PubkeyRouter: '0x4B5E97F2D811520e031A8F924e698B329ad83E29',
  PKPNFT: '0x58582b93d978F30b4c4E812A16a7b31C035A69f7',
  RateLimitNFT: '0x19593CbBC56Ddd339Fde26278A544a25166C2388',
  PKPHelper: '0xF02b6D6b0970DB3810963300a6Ad38D8429c4cdb',
  PKPPermissions: '0xD01c9C30f8F6fa443721629775e1CC7DD9c9e209',
  PKPNFTMetadata: '0xeD46dDcbFF662ad89b0987E0DFE2949901498Da6',
  Allowlist: '0xfc7Bebd150b36921549595A776D7723fBC4Bb2D9'
}

[Ansonhkg]

lgtm!

[joshLong145]

Approving as the polyfill has been tested.

[Ansonhkg]

lgtm