Add Validation classes and types

[kuzdogan]

Fixes #1821

PR to be merged to the main Verification Refactoring flow. I'll be documenting the changes and rationale along the way.

• Current validation.ts and the way we create CheckedContracts from files is by first splitting the files as metadata and sources. Then we take variations of all source files and from them we find the correct sources for each metadata. I decided to move the variation step into SolidityMetadataContract class. The downside is we might need to run "variation" and keccaking steps multiple times for each source file, when there are multiple metadata and a set of source files in the current files array. However, our API will accept a single metadata. So I don't expect this to happen in practice a lot. Even if it happens it's should be still ok, even if hashing could be a little expensive. This way it's cleaner conceptually, as all the mapping, variation etc. is within the class.
• Note: We have JsonInput type for Solidity but VyperJsonInput type for Vyper
• Methods related to finding auxdatas require the legacyAssembly compilation output. So it need compilation to have run once during verification. Therefore it should be under SolidityVerification. generateEditedContract can be under SolidityCompilation

TODO:

• Leave outputSelection empty and handle that in Compilation
• Do fetchMissing in async createCompilation()
• rename checkFiles... to createMetadataContractsFromFiles
  • Remove everything name after "checked... "check...
• Try first assembling the contract without variations, only try after if it doesn't work

[kuzdogan]

Requesting an interim review before adding tests @marcocastignoli

[marcocastignoli]

Just a few comments in particular for renaming and moving staff around.

After solving the comments I think we can proceed by:

• merging this back in the main PR
• create a new PR in which we adjust Validation to use the new types from Compilation
• create a new PR in which we create Validation tests

[marcocastignoli]

Why do you need this? shouldn't test/*.spec.ts be already included in the superset test/**/*.spec.ts?

[kuzdogan]

Yes, but for some reason it didn't do it for me 🤷

[marcocastignoli]

in any case we should split the test files in their own folders

[kuzdogan]

Yes so you mean test/Validation/xxx.spec.ts test/Compilation/xxx.spec.ts?

[marcocastignoli]

Yes

[marcocastignoli]

Regarding this, I reiterate what I said yesterday, I would like the final library to be used like this:

import {Validation, Compilation, Verification} from "@ethereum-sourcify/lib-sourcify";

const metadataContracts = Validation.createMetadataContractsFromPaths(...)

const metadataContract = new Validation.SolidityMetadataContract(...)

What do you think? If you like it, then we can rename this file as validation.ts (like an index of this folder), in which we export everything related to validation:

• the functions already in this file
• and we import/export SolidityMetadataContract

[kuzdogan]

Do we need the Validation. prefix? There's only the SolidityMetadataContract class. We can move this function as a static function to SolidityMetadataContract.createMetadataContractsFromPaths.

But I also liked your version. How does it look for Compilation and Verification, let's think about that.

[kuzdogan]

Ok let's go with your way, it's nice. How do we do that do we declare a Validation class or a namespace, or function?

[marcocastignoli]

I think we can just export a default object with all the needed classes / functions in an index file

// index.ts
export default {
  Validation:{},
  Compilation:{},
  Verification:{},
}