Standardising on errors in implementations

[vmx]

I had another look at the block API rm tests to improve the error handling of the test.

Currently the error from the datastore implementations just bubble up. So in case of a block rm I got:

{ [Error: ENOENT: no such file or directory, unlink '/tmp/ipfs-test-72e2ac95f367457c10d27493ae180348/blocks/QP/CIQJUEPSMDQEKVS7XM6EVFOUIQK2QLXKMDQHGDQBQ7X76O23KCRWQPI.data']
  errno: -2,
  code: 'ENOENT',
  syscall: 'unlink',
  path:
   '/tmp/ipfs-test-72e2ac95f367457c10d27493ae180348/blocks/QP/CIQJUEPSMDQEKVS7XM6EVFOUIQK2QLXKMDQHGDQBQ7X76O23KCRWQPI.data' }

Which is very implementation specific. The error should rather be similar to Go-IPFS's HTTP Error:

"Error":"blockstore: block not found"

After reading ipfs/js-ipfs#1406 and ipfs/js-ipfs#1506 (comment) and seeing that there's already a file with errors using err-code, I think it would make sense to use those errors also in the implementations. We could then even have tests in this repo, testing for those errors.

[jacobheun]

We recently added a basic test for gets with the recent error code additions, https://github.com/ipfs/interface-datastore/pull/22/files. Ideally we'd have more tests for the various error states, but one of the difficulties with that is the various implementations error in different ways. For example a put failure on datastore-level vs datastore-s3 are going to have different root causes.

Perhaps we could do something to the base test suite here to throw failures unless certain tests are overridden?