Feature/Replication Manager v3

[telamon]

Description

I've rewritten the replication management that was previously located in mux.js
and moved it out into a separate module.

The motivation behind the code separation was driven by the need to use a single
peer connection to replicate multiple 'multifeeds'.

Which in turn led me to the idea that replication and storage management dosen't necessarily
have to be done by the same module.

This enables multifeed to share a replication manager with other core stores or lazily
initialize it's own replication manager when replicate() or the new use() method is invoked.

Multifeed's tests were not modified and were used as proof of fittness for the new replication manager.
Due to the rewrite of error handling we're seeing new warnings during the test-suite run.

Which I believe is positive since we had no feedback nor handling during those states before.
I hope that I have improved the stability as a whole.

The new middleware API allows multifeed dependents to control replication on application level.

I wonder if it could be used to implement a cabal-core#55 exile-filter...

Todo

Tasks left before merge:

• Merge latest multifeed. conflict resolved.
• Add docs for the new use() method
• Add docs for opts.headerOrigin

[hackergrrl]

Is this obsolete now that decentstack exists?

[telamon]

Hmm. no it's still the same experimental working branch. let me do a push to update it.

[hackergrrl]

Based on some conversations with @telamon, we're not going to proceed with this specific approach. Thank you @telamon ❤️