[ts-sdk] Incosistent reply on iotaClient depending on transport protocol

[lzpap]

Bug description

I noticed an incosistency in the TS SDK's IotaClient which prevents me from accessing the response of a getObject() call.

Version

@iota/iota-sdk 1.7.1

Steps To reproduce the bug

1. Create a new IotaClient with graphql as the transport protocol:

    const client = new IotaClient({
        transport: new IotaClientGraphQLTransport({
            url: networkGraphqlUrl,
            fallbackTransportUrl: networkJsonRpcUrl,
            unsupportedMethods: [
                'multiGetObjects',
                'getReferenceGasPrice',
                'getNormalizedMoveFunction',
                'getOwnedObjects',
                'dryRunTransactionBlock',
                'executeTransactionBlock',
            ],
        }),
    });

2. Use the client to execute a getObject call for a non-existent object in the ledger.
3. The returned IotaObjectResponse value is undefined.

Expected behaviour

In case of JSON RPC transport, an error is returned. Such error is not returned through the GraphQL interface, so the SDK can't show it, but at least the "data" field of the response should be set to null in order for clients to recognize that the obejct doesn't exist.

Actual behaviour

The sdk fails to interpret the response from the graphQL RPC, which looks like this:

{
  "data": {
    "object": null
  }
}

Note, that in case the obejct does exist, the SDK can parse the response from GraphQL RPC into a valid IotaObjectResponse.