Long running preload calls waste bandwidth

[lidel]

Found when testing embedded js-ipfs in Brave (#716)

Problem

When browsing resource with big DAGs, the cost of preload calls executed in the background becomes significant. The API returns CID of every child, and entire call can run for many minutes and not only block the preload queue (limited to 4 concurrent requests), but eat multiple megabytes over 3+ minutes:

Test

$ curl 'https://node0.preload.ipfs.io/api/v0/refs?r=true&arg=QmRn43NNNBEibc6m7zVNcS6UusB1u3qTTfyoLmkugbeeGJ' --compressed > refs-r-QmRn43NNNBEibc6m7zVNcS6UusB1u3qTTfyoLmkugbeeGJ

Fix

TBD.

• Need to introduce configurable limits for preload calls (time? response size?) in js-ipfs. This may be a global high watermark for all "delegated" modules (preload & delegated routing)
• We could also investigate adding silent mode to the API, but this sounds like an overkill, and even if we do this, won't get shipped with go-ipfs any time soon, so need to solve it on the client

[lidel]

Superseded by #967