Maximally transfer name reinterpretation responsibility from client to server in Omnigraph API

[lightwalker-eth]

The reinterpretName utility function is a nice touch we've implemented for strong change management maturity between clients / servers.

That being said, it's an unfortunate burden on apps integrating with the Omnigraph API to call reinterpretName themselves.

I need to double check -- I think we might already be implementing this inside the Omnigraph client implementation inside enssdk?

If so, that's a nice touch, but it will still be a complication for apps making use of the raw GraphQL API, such as clients implemented in languages other than TypeScript who don't have easy use of enssdk.

Here's an alternative idea:

• Add an optional HTTP header on each request to the Omnigraph API that identifies the client's ens-normalize version implementation relative to Raffy's ens-normalize package versions (even if they are using an alternative implementation in another language, they can figure out how their implementation relates to a version of Raffy's Typescript package).
• Update ENSApi so that it doesn't just import a single version of Raffy's ens-normalize package, but a specific set of versions.
• When the Omnigraph API is returning an InterpretedName value to the client, it could take on the responsibility of reinterpretation for the client as follows:
  • If there's no ens-normalize package version number reference in the HTTP header, perform no reinterpretation
  • If there's an ens-normalize package version number reference in the HTTP header:
    • If that package version number is > the package version number ENSApi already used to generate it's InterpretedName (and therefore isn't in the set of ens-normalize package imports available to ENSApi) then do nothing. Changes to ens-normalize across time (with higher version numbers) should only increase the set of what can be normalized and never reduce it.
    • If that package version number is === the package version number ENSApi already used to generate it's InterpretedName then do nothing, already good to go.
    • If that package version number is < the package version number ENSApi already used to generate it's InterpretedName:
      • If ENSApi includes an import of the specifically requested earlier package version of ens-normalize, perform reinterpretation inside ENSApi using the specifically requested earlier package version.
      • Else, Invalid Request error.
• Update enssdk so that it automatically adds it's ens-normalize version in the HTTP headers with each request it sends to the Omnigraph API.

Goals include:

• ENSAwards should be able to completely remove any calls to reinterpretName (with an exception for API calls it's making to non-Omnigraph APIs)