Decentralized network: support for fallback

[dotansimha]

The goal of this issue is to address a pain point when working with multiple, decentralized indexers. Some GraphQL schemas might be consumed through multiple GraphQL endpoints, from different indexers.
Some indexers might not be available, so we aim to allow the option to fallback on a schema source (maybe also fallback to the hosted service)

[ardatan]

Do we count GraphQLErrors returned from 200 response body's errors as errors as well or just HTTP errors?

[dotansimha]

Do we count GraphQLErrors returned from 200 response body's errors as errors as well or just HTTP errors?

@lutter @azf20 @ what do you think?
I think most of the indexing/runtime/validation errors are returned from graph-node / gw in a valid structure for GraphQLError? ({ errors: { message: string }[], data?: any })? so we can treat those are actual errors in the client?

For the network errors, we should definitely use those are trigger for retry/fetch.

Btw, also worthing about thinking on a sensible default for timeouts? (@ardatan we can have this as another composable strategy right? )

- handler: graphql
  source:
    - type: retry
      source:
        type: timeout
        value: 10ms
        source:
          type: endpoint
          uri: http://graphql/

[azf20]

Looks good! Yes I think that a lot of graph-node errors return a 200 response with errors in the body so we can treat them as errors in the client.

[dotansimha]

Done in #7