docs: async migration

[vasco-santos]

In the context of js-libp2p being a skeleton project, when a new user tries to use this there is a probability of hitting problems, as a consequence of the on going efforts to migrate the codebase to async. For instance, if we try to install libp2p-bootstrap to use in the bundle, it will use the newest version by default, which is already migrated, taking problems to js-libp2p, which still expects callbacks.

This PR adds a note to new users in the README

[didlie]

I think the issue is that code migration to satisfy syntax is destructive to branch developers and almost irrelevant. Whatever code style was chosen and used to create a working and usable project, that is the code that should continue to be maintained and working. if obfuscation and annoyance and wasted time is the goal, then migrate the code bit-by-bit and ruin working branch applications and invalidate ports of the project... by all means.

[vasco-santos]

@didlie I agree with avoiding immediate breaking changes, especially if they are really impactful. However, in this case, we have been talking about this since last year #266

The main goals with this change are to improve the efficiency of the codebase, decrease the bundle size of js-libp2p and provide an improved developer experience to the libp2p users. Supporting and maintaining the current implementations would not allow anything of this.

With this PR we are essentially pointing this information to new contributors, who would start a new project and try to use the latest versions of each libp2p modules, which is still not supported. For ongoing projects, each module that got upgraded was released as a breaking change, and users will be able to see if they should update to the newest version of a module, or wait until all the code migration is complete (until getting into js-libp2p).

[didlie]

it will make the code more condense and less readable and less adaptable...why not just let it be compiled? compilation size should be identical.

[mikeal]

@didlie compilation won’t fix the pull-stream issues. this isn’t just a style change, the actually semantics of how data is processed change and are cleaned up quite a bit by migrating to async iterators.

[didlie]

@mikeal there is nothing unethical about mixing code versions in a single repo. It can actually help developers distinguish.

[jacobheun]

👍
I've updated the comment at #266, to include the current supported minor version list of packages. We will update that as support is completed.

I appreciate the discussion on the impacts of the migration, but for visibility these should be done in the parent issue for async/await, ipfs/js-ipfs#1670.

This PR is to help inform about the current efforts already underway.