Subgraph validation and normalization

[Jannis]

Validation

• [x] Validate subgraph manifest using a GraphQL schema #147
• [x] Validate the subgraph's GraphQL schema #149
• [x] Validate ABIs in the subgraph
• [x] Validate that events are present in ABIs (depends on event signature normalization)
• [ ] Validate that no entity derives two fields from the same field of another entity in the schema
• [x] Validate that all field types in the schema are valid (common problem: Address)
• [ ] Validate that field names do not match reserved AssemblyScript words (e.g. public)
• [x] Validate that reference fields refer to existing entities
• [x] Validate that all entity types have an id field of type ID!
• [x] Validate that all contract addresses in the manifest are valid

Normalization

• [ ] Normalize subgraph manifest (deterministic field and list item order etc.)
• [ ] Normalize event signatures (e.g. uint -> uint256, no parameter names, no spaces)
• [ ] Normalize GraphQL schemas (deterministic type and field order)
• [ ] Normalize mappings (e.g. format with prettier)

[leoyvens]

The normalization plan is under the assumption that we're going to read a yaml, normalize it, output another yaml and hash that. One thing that would complicate this is supporting subgraph manifests in json format, which would require a step converting the json to yaml. But the other way around of converting yaml to json seems simpler, and json also has the advantage of being easier to put in a canonical shape since it doesn't care about whitespace.

The point is that if we'll support both yaml and json manifests, we should consider having json be the canonical format because it's simpler.

[Jannis]

Agreed! The above doesn't make any assumptions like that though — only the current PR does. But YAML is what we use right now, so it seems appropriate. Plus the logic there should also work for JSON.

[leoyvens]

@Jannis wanna check off all that got done here?

[Jannis]

@leodasvacas Done, I would've forgotten :)