GraphQL route for dumping entity changes in subgraph and block

[neysofu]

Closes #3274.

The GraphQL API implemented here looks like the following (a bit different from #3274's first draft; after collecting feedback):

type Query {
  entityChangesInBlock(subgraphId: String!, blockNumber: Int!): EntityChanges!
}

type EntityChanges {
  updates: [EntityData!]!
  deletes: [String!]!
}

type EntityData {
  name: String!
  fields: [EntityField!]!
}

type EntityField {
  field: String!
  valueAsJSON: String!
}

[lutter]

Nice! Looks good so far!

[Jannis]

One last request: can we ensure that all returned values are sorted deterministically so we don't have to do it in the client? I see we're doing it for entity fields, but not for entities, entity types, deletions etc.

[neysofu]

One last request: can we ensure that all returned values are sorted deterministically so we don't have to do it in the client? I see we're doing it for entity fields, but not for entities, entity types, deletions etc.

Yeah, that would be a good idea. Any reasonable order (e.g. ID, alphabetic) as long as it's deterministic?

[Jannis]

One last request: can we ensure that all returned values are sorted deterministically so we don't have to do it in the client? I see we're doing it for entity fields, but not for entities, entity types, deletions etc.

Yeah, that would be a good idea. Any reasonable order (e.g. ID, alphabetic) as long as it's deterministic?

I'd order type names alphabetically, and then the entities by ID (alphabetically again).

[Jannis]

@neysofu Another small request: There are a few tables in deployment schemas that are internal, e.g. poi$, poi2$. It would be good to exclude those in the SQL query so we don't leak internals and raw POIs to others.

I think after that we're done here, I've tested the PR and it works great!

[neysofu]

@Jannis I'm also removing __typename since it's redundant data.

[Jannis]

Fantastic!

Addressed all questions and refactored x-checking logic between updates and deletions.