fix: make local peer id optional

[achingbrain]

libp2p@2.x.x will remove the localPeer argument from the secureInbound and secureOutbound methods of the ConnectionEncrypter interface - see libp2p/js-libp2p#2304.

Unfortunately the js-libp2p monorepo has a depdendency on this module so the change cannot be released until this module is compatible... with the unreleased change.

This PR tests the first argument to secureInbound and secureOutbound to ensure that it is actually a PeerId. If not it shuffles all the arguments along by one place. This makes @chainsafe/libp2p-noise compatible with both libp2p@1.x.x and libp2p@2.x.x.

This PR can be reverted and the first argument removed once libp2p@2.x.x is released.

[wemeetagain]

Won't there still be type errors since the interfaces don't match?

[achingbrain]

I think there will be breakage after the v2 release:

• @chainsafe/libp2p-noise currently resolves to the @libp2p/interface in the monorepo
• We have "skipLibCheck": true in the js-libp2p monorepo tsconfig.json so it doesn't check the types of @chainsafe/libp2p-noise
• When we release v2, @chainsafe/libp2p-noise will resolve to the older @libp2p/interface version
• At that point I think tsc will go 💥

[achingbrain]

Maybe we'll need to do a major here shortly after the v2 release that updates the interface version, then a follow up that upgrades libp2p to the new noise major.

There will be a short window where things are broken but I'm not sure how else we can resolve the circular dependency, other than adding noise to the libp2p monorepo.

I am open to ideas 😅

[wemeetagain]

Can we cut a breaking release here that relies on a 2.0-compatible commit of libp2p/interface? then after 2.0 is released, rely on the official upstream again.

Eg:

• publish 16.0 here that relies on commit xxxx-2.0 of libp2p (this could additionally be published with a next or beta dist-tag)
• publish libp2p 2.0 relying on noise 16
• publish 16.0.1 that relies on upstream libp2p 2.0 (and publish with the normal dist-tag)

[achingbrain]

Actually I wonder if we could use method overloading to be compatible with both versions of the interface?

Deps would get duplicated but tsc should be happy.

[wemeetagain]

method overloading

worth a shot, should be able to be tested locally for build errors

[wemeetagain]

LGTM