Automatically lower-case address inputs

Do you want to request a feature or report a bug?
Both?

What is the current behavior?
A common pitfall for new users of The Graph is the ID or a Bytes fields actually contain an Ethereum address. When trying to query for that address with EIP-55 checksummed mixed-case strings or upper-case strings there is no match. Without further knowledge of the inner workings of the graph-node, this is a break in the developer journey. For example: "I know this address has a Punk but the subgraph does not show it. So it must be broken"

If the current behaviour is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

• Open a Subgraph, for example: https://thegraph.com/hosted-service/subgraph/itsjerryokolo/cryptopunks
• Send a query with checksummed address:

{
  accounts(where: {id: "0xF22F00D0B95B1b728078066E5f4410F6B2Be8faE"}) {
    averageAmountSpent
    id
  }
}

What is the expected behavior?

Same as when sending this query to the above subgraph:

{
  accounts(where: {id: "0xf22f00d0b95b1b728078066e5f4410f6b2be8fae"}) {
    averageAmountSpent
    id
  }
}

Proposed steps
Since we don't know from the schema if an ID or Bytes field actually does contain an Ethereum address, I propose to do the following steps:

• Check if the input string is an Ethereum address and the queried field is ID or Bytes. /^0x[a-fA-F0-9]{40}$/
• For Bytes: Lowercase the input string before sending to the database
• For ID: (This is a bit tricky): Maybe try to send the query and if it is null, resend it with lower-cased input?

Remarks
The possible solution here is good for backwards compatibility of subgraphs and probably easy to implement. A better long-term solution would be the introduction of an Address scalar type.

Gehe vom für das accounts-id-Feld gezeigten GraphQL-Abfrageverhalten aus und vergleiche Adressen mit Checksumme oder in Großschreibung mit der Abfrage in Kleinbuchstaben. Kläre, ob die Normalisierung auf Bytes, ID oder beide angewendet werden sollte, und definiere das erwartete Fallback-Verhalten, bevor du das Ergebnis implementierst und testest.