Turn on query diffing

[stubailo]

We have the capability to diff a new query against the the store to avoid fetching data we already have. Currently, that functionality is not exposed through index.js at all. There are some tests, but any new query passed to watchQuery is run against the server in its entirety. We should add this functionality.

Options

There are 3 variants (with small deviations) of what you might want to do when fetching a new query:

1. Do not diff against the store, always fetch the entire new result (what we do now)
2. Use the cache if the whole result is there, but if only part of it is available, send the whole new query
   1. Only call the onResult callback when the server response returns
   2. Call onResult immediately with partial data, then again with complete data
3. If the server follows the Relay object ID spec, send a minimal set of queries to the server to fetch the data we don't have yet
   1. Same as 2.i
   2. Same as 2.ii

This means there are several bits of data required to pick a fetching strategy for a particular query:

1. Knowledge about what the server supports (for example, can we refetch a single node by ID?)
2. Do we definitely want up-to-date data for this query (should we use the cache at all)
3. Is partial data preferable to no data at all (should we return partial data from the cache immediately)

(1) should be determined when instantiating the client, and (2) and (3) should be options to watchQuery.

Defaults

I think the default should be the least surprising set of options, which makes no assumptions about the environment:

1. Assume the server doesn't support Relay
2. Assume every query should fetch from the server
3. Assume partial data is not OK

There's a small cost that uninformed users will assume the client doesn't have these features, but it's up to us to make them easily discoverable.

[stubailo]

@jbaxleyiii question:

Should the information about what the server supports live in the network interface? For example, this would be a flag supportsRelayNodeQueries or something.

[jbaxleyiii]

@stubailo I think so. To me the network interface both declares how to communicate to an external source, as well as other potential information. For instance, at some point I think we build authentication that is passed / provided by the network interface.

This keeps the main data logic separate from the data source making it possible to point to different types of graph servers, as well as opens the option to setup a client side graph endpoint for local state

[stubailo]

Yep, that's what I was thinking as well. Might build passing options about what the server supports as part of #43