Network timeouts on blocks (i.e. genesis block for incentivised testnet)

[lewnelson]

Describe the bug
When fetching genesis block data on the GraphQL API if the genesis block contains hundreds of thousands of addresses on transactions then there are network performance issues.

See explorer https://shelley-testnet-explorer-staging.netlify.com/en/blocks/ last page of table for example.

Example request which fails

POST https://explorer.incentivized-testnet.iohkdev.io/explorer/graphql

{
    block(id:"7be0014ffe4e5fd74aeb2916bd85cbfdaf52c2d738e4883f4cf52f6f695a6e2d") {
        transactions {
            edges {
                node {
                    inputs {
                        amount
                        address {
                            id
                        }
                    }
                    outputs {
                        amount
                        address {
                            id
                        }
                    }
                }
            }
        }
    }
}

Removing the inputs and outputs from the transaction solves the issue. However for the explorer we use the transaction inputs and outputs amounts to calculate fees and output. This may be mitigated from the genesis block, but won't be as easy to do on random blocks given we don't know the size of the data.

Mandatory Information
Incentivised node https://explorer.incentivized-testnet.iohkdev.io/

1. jcli --full-version output;
2. jormungandr --full-version output;

To Reproduce
Steps to reproduce the behavior:

1. Go to the explorer https://shelley-testnet-explorer-staging.netlify.com/en/blocks/
2. Click on the last page for the table
3. Check the network tab to see the timeout

Expected behavior
Expected the network not to timeout handling the large amount of data. It may be beneficial to query for totals instead of doing the calculations from the data received.

Additional context
Add any other context about the problem here.

[ecioppettini]

Although I know of a few things that can be optimized for that query, I think in this case it's just not feasible to send that amount of data in one chunk. I think adding the aggregations on the backend is the only way this is going to work, maybe for the entire block, or for each transaction. Any thoughts @NicolasDP ?