Making sure that a DAT is closed in the correct order

[martinheidegger]

Hypercore introduced errors that might occur if something is read while closing. When DAT closes it has become more important to close the network and file-import
before the archive is closed.

This PR makes sure that the DAT is destructed in the proper order.

[joehand]

I merge this because node v8 was passing and node v10 was okay but getting memory error in test (which happens sometimes). But now I am getting an error in the tests locally as well, same as error on Travis here: https://travis-ci.org/datproject/dat-node/jobs/468113136#L489.

ok 20 network is open
  dat-node leaveNetwork() +50ms
  dat-node Stream close +3ms
  dat-node Replication stream ended +1ms
  dat-network Downloaded data: 1657 +0ms
  dat-network Downloaded data: 1657 +502ms
  dat-node Stream close +881ms
events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: Feed is closed
    at Feed._onclose (/Users/joe/code/node_modules/dat-node/node_modules/hypercore/index.js:1125:34)
    at /Users/joe/code/node_modules/dat-node/node_modules/hypercore/index.js:1115:38
    at Request.done [as _callback] (/Users/joe/code/node_modules/dat-node/node_modules/hypercore/lib/storage.js:203:5)
    at Request.callback (/Users/joe/code/node_modules/dat-node/node_modules/random-access-storage/index.js:161:8)
    at onclose (/Users/joe/code/node_modules/dat-node/node_modules/random-access-file/index.js:117:9)
    at /Users/joe/code/node_modules/dat-node/node_modules/nyc/node_modules/graceful-fs/graceful-fs.js:43:10
    at FSReqWrap.oncomplete (fs.js:141:20)
Emitted 'error' event at:
    at onerror (/Users/joe/code/node_modules/dat-node/node_modules/hyperdrive/index.js:92:19)
    at Object.loop [as callback] (/Users/joe/code/node_modules/dat-node/node_modules/hyperdrive/index.js:139:21)
    at Feed._onclose (/Users/joe/code/node_modules/dat-node/node_modules/hypercore/index.js:1125:25)
    at /Users/joe/code/node_modules/dat-node/node_modules/hypercore/index.js:1115:38
    [... lines matching original stack trace ...]
    at FSReqWrap.oncomplete (fs.js:141:20)

[joehand]

Oh is this dependent on holepunchto/hyperdrive#231 ?

[martinheidegger]

In a way... It is related but not depended. The reason why it works in Travis might be the package-lock.json contains an old hypercore version that doesn't throw that error.

Note: I think the package-lock should not be part of any library's repo.

[joehand]

Note: I think the package-lock should not be part of any library's repo.

Makes sense, removed it. Definitely not the first time we've had weird errors because of it.