fix(ci): avoid fs clash during ipfs.add* on Windows

[lidel]

This PR fixes random TravisCI failures on Windows and unblocks ipfs/js-ipfs#2304

Root cause

Windows issue was triggered by parallel ipfs.add* of the same data:

      parallel({
        result: (cb) => ipfs.addFromURL(url, cb),
        expectedResult: (cb) => ipfs.add(Buffer.from(text), cb)
      }, (err, { result, expectedResult }) => {
        expect(err).to.not.exist()

Both addFromURL and add added the same data, touched same files on filesystem, triggering a known problem with Node on Windows and Travis:

• https://travis-ci.community/t/eperm-operation-not-permitted-nodejs-electron/2571

Fix

One way to fix this type of error is to run as Windows Administrator. It does not seem to be feasible for TravisCI.

Instead, switching to sequential mode of operation removes addFromURL tests as a surface for file system race conditions on Windows.

[alanshaw]

The fix for this is ipfs/js-datastore-fs#27

[hugomrdias]

The fix for this is ipfs/js-datastore-fs#27

That was merged into 0.8.x branch and ipfs-repo is on 0.9.x
@achingbrain do we need to port it to master ?

[achingbrain]

The PR for the 0.9.x branch is ipfs/js-datastore-fs#28

[lidel]

Should we close this, and bubble up the datastore fix instead?

[lidel]

Closing, as ipfs/js-ipfs#2304 confirmed this is fixed in js-datastore-fs