chore: run interop tests as part of the build

[achingbrain]

This will need updating to only run on master & add npx aegir update-last-successful-build from ipfs/aegir#419 as a post-build step

[hugomrdias]

can you use https://github.com/hugomrdias/connect-deps instead of npm link please ?

[achingbrain]

can you use https://github.com/hugomrdias/connect-deps instead of npm link please ?

Sure. I copied the commands from https://github.com/ipfs/interop - can you PR into the README there to update them?

[achingbrain]

I guess something I don't like about this is that a PR could pass CI and be merged, then break master due to an interop test failing. Maybe we should run them on every branch?

[achingbrain]

We should probably include them as a devDep at that point, otherwise specifying which version of the interop tests should run becomes hard (e.g. breaking changes, new tests, etc).

[daviddias]

Pretty cool

[daviddias]

scary. What happened?

[daviddias]

nvm. Read the commit message

[achingbrain]

In a nutshell we have too many modules that are written as if they exist independently of each other.

1. A patch-release of multiformats/mafmt pulled in multiaddr@v7, broke this comparison and caused tests to fail with:

AssertionError: expected '/ip4/127.0.0.1/tcp/45467/ipfs/QmXLcgh85JSbd2v6zsFgu68fjeqsaqGLapFD5MxHLpEwtW/ipfs/QmXLcgh85JSbd2v6zsFgu68fjeqsaqGLapFD5MxHLpEwtW\n' to deeply equal '/ip4/127.0.0.1/tcp/45467/ipfs/QmXLcgh85JSbd2v6zsFgu68fjeqsaqGLapFD5MxHLpEwtW\n'
      + expected - actual

2. Only forward, so I upgraded js-ipfs and js-ipfs-http-client to multiaddr@v7, tests passed so published ipfs-http-client@35 with the new multiaddr with a view to PRing it into js-ipfs
3. ipfsd-ctl upgraded ipfs-http-client to 35 in 0.46.1
4. Lots of the js-ipfs dependency tree has multiaddr@v6, cannot upgrade right now because of the scope of API changes
5. I asked @vasco-santos to downgrade multiaddr in mafmt instead, published as v0.6.10
6. Now we need js-ipfs-http-client@34.0.0 which is in ipfsd-ctl@0.46.0 but not ipfsd-ctl@0.46.1 so as a stop gap, pin ipfsd-ctl@0.46.0, so we can run the interop tests on CI and fix the build

This weird js-ipfs, js-ipfs-http-client, js-ipfsd-ctl version dance is what I'm talking about in #2446

Anyway, next steps:

1. Assuming CI passes on this PR, integrate interop test running with v0.38.x branch (today)
2. Run tests of webui, desktop, companion, etc as per new release process (tomorrow)
3. Start community dev testing of v0.38.x (tomorrow/Monday)
4. Upgrade libp2p, ipfs-repo, etc (Monday/Tuesday/Most of next week)

[achingbrain]

I'm going to merge this because the new interop bits of the build are passing, the failing bits are the electron-render related stuff @hugomrdias is fixing in ipfs-inactive/js-ipfs-http-client#1105