Make ls links' depth dynamic.

[JonKrone]

To be able to prettily print ipfs ls -r, we need to know the depth of each file from the ls command.

It was previously hardcoded a 1, though I don't know why. I'm passing the depth along from a change I made in js-ipfs here.

The b58 hash test for ls should fail in CI because the above change to js-ipfs is required to receive the links' depth. Unfortunately this is a cyclical dependency. I can fix it by breaking out the change to js-ipfs or we can merge and fix if something comes up. lemme know

ref: ipfs/js-ipfs#1222

[daviddias]

@JonKrone CI fails because tests fail: https://travis-ci.org/ipfs/js-ipfs-api/jobs/342470865#L6136-L6193

[JonKrone]

The b58 hash test for ls should fail in CI because the above change to js-ipfs is required to receive the links' depth. Unfortunately this is a cyclical dependency. I can fix it by breaking out the change to js-ipfs or we can merge and fix if something comes up. lemme know

Preferred approach?

[daviddias]

js-ipfs is required to receive the links' depth.

@JonKrone js-ipfs-api is tested against go-ipfs, not js-ipfs. No change in js-ipfs should be required.

[JonKrone]

@diasdavid Thanks! I did something that made these tests pass at one point but I must've mislead myself. Lots to these projects. Anyhow, just made a change, let me know if it's not the right way to go.

When a feature of js-ipfs diverges from go-ipfs and requires a change in a dependency that uses both go-ipfs and js-ipfs, how do we handle that? I know we want to maintain as much similarity as possible but are the interfaces a core that we can extend or do we want to strictly maintain them? Should we update any interfaces for this change?

[JonKrone]

Tests failed this time due to an OOM, heap out of memory: https://travis-ci.org/ipfs/js-ipfs-api/jobs/343565256#L3547

[daviddias]

Thanks @JonKrone!

Tests failed this time due to an OOM, heap out of memory

Just the browser ones and on CI given #683. Still figuring that one out.