Add better error checking for fetched GraphQL requests

[MartinMinkov]

Description

This PR introduces enhanced error handling for GraphQL network requests within the Fetch module. Previously, if a GraphQL request failed, the error output would be presented as statusText in an array format. This made error reporting from the user's application less informative, as it logged [object Object]. An example of this less descriptive error logging is as follows:

> npm run build && node build/src/index.js

> test-graphql-errors@0.1.0 build
> tsc
/home/martin/Code/o1/mina/src/lib/snarkyjs/dist/node/_node_bindings/snarky_js_node.bc.cjs:7427
         throw err;
         ^
Error: [object Object]
    at fetchEvents (file:///home/martin/Code/o1/mina/src/lib/snarkyjs/dist/node/lib/fetch.js:475:15)
    at process.processTicksAndRejections (node:internal/process/task_queue:95:5)
    at async main (file:///tmp/test-graphql-errors/build/src/index.js:3:20)

This error as produced by building snarkyjs with an invalid GraphQL schema in the request for fetchEvents.

With the enhancements made in this PR, the error reporting becomes more informative and user-friendly. The new error messages provide specific details about the issues at hand. An example of the improved error message is:

> npm run build && node build/src/index.js                         

> test-graphql-errors@0.1.0 build
> tsc
/home/martin/Code/o1/mina/src/lib/snarkyjs/dist/node/_node_bindings/snarky_js_node.bc.cjs:7427
         throw err;
         ^
Error: Cannot query field "events1" on type "Query". Did you mean "events"?
    at fetchEvents (file:///home/martin/Code/o1/mina/src/lib/snarkyjs/dist/node/lib/fetch.js:475:15)
    at process.processTicksAndRejections (node:internal/process/task_queue:95:5)
    at async main (file:///tmp/test-graphql-errors/build/src/index.js:3:20)

Testing

The improvements introduced in this PR have been verified using a local test script.

[shimkiv]

LGTM

[mitschabaude]

just double-checking -- are we sure that undefined response data always means that the request failed?

[MartinMinkov]

Good call. I believe this to be the case since we check that jsonResponse.data exists when we try to do some processing on later functions:

• https://github.com/o1-labs/snarkyjs/blob/2fa164ef19ae2d24acb412a22e27f2e58ba71aec/src/lib/fetch.ts#L489
• https://github.com/o1-labs/snarkyjs/blob/2fa164ef19ae2d24acb412a22e27f2e58ba71aec/src/lib/fetch.ts#L635
• https://github.com/o1-labs/snarkyjs/blob/2fa164ef19ae2d24acb412a22e27f2e58ba71aec/src/lib/fetch.ts#L840
• https://github.com/o1-labs/snarkyjs/blob/2fa164ef19ae2d24acb412a22e27f2e58ba71aec/src/lib/fetch.ts#L908

I'm not sure of a case where we would make a GraphQL request and expect the data to be undefined. Even if we make a GraphQL mutation instead of a query, we would probably want some data returned (e.g. an ID).

[mitschabaude]

Ok I guess we can look at our current queries to check that we always want something returned, and this is currently the case 👍🏻