…ibp2p#2752)

Document that the `ConnectionHandler` implementation has to enforce a limit on
the number of inbound substreams.

…ibp2p#2734)

* misc/metrics: Explicitly delegate event recording to each recorder

This allows delegating a single event to multiple `Recorder`s. That enables e.g. the
`identify::Metrics` `Recorder` to act both on `IdentifyEvent` and `SwarmEvent`. The latter enables
it to garbage collect per peer data on disconnects.

* protocols/dcutr: Expose PROTOCOL_NAME

* protocols/identify: Expose PROTOCOL_NAME and PUSH_PROTOCOL_NAME

* protocols/ping: Expose PROTOCOL_NAME

* protocols/relay: Expose HOP_PROTOCOL_NAME and STOP_PROTOCOL_NAME

* misc/metrics: Track # connected nodes supporting specific protocol

An example metric exposed with this patch:

```
libp2p_identify_protocols{protocol="/ipfs/ping/1.0.0"} 10
```

This implies that 10 of the currently connected nodes support the ping protocol.

…nd,address_change,close}` (libp2p#2724)

Instead of having a mix of `poll_event`, `poll_outbound` and `poll_close`, we
flatten the entire interface of `StreamMuxer` into 4 individual functions:

- `poll_inbound`
- `poll_outbound`
- `poll_address_change`
- `poll_close`

This design is closer to the design of other async traits like `AsyncRead` and
`AsyncWrite`. It also allows us to delete the `StreamMuxerEvent`.

* build(deps): Bump Swatinem/rust-cache from 1.4.0 to 2.0.0

Bumps [Swatinem/rust-cache](https://github.com/Swatinem/rust-cache) from 1.4.0 to 2.0.0.
- [Release notes](https://github.com/Swatinem/rust-cache/releases)
- [Changelog](https://github.com/Swatinem/rust-cache/blob/master/CHANGELOG.md)
- [Commits](Swatinem/rust-cache@cb2cf0c...6720f05)

---
updated-dependencies:
- dependency-name: Swatinem/rust-cache
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Follow up on libp2p#2724. Given that
libp2p-core is bumped to v0.35.0, libp2p-tcp needs to be bumped as well.

….0 (libp2p#2761)

* build(deps): Update prometheus-client requirement from 0.16.0 to 0.17.0

Updates the requirements on [prometheus-client](https://github.com/prometheus/client_rust) to permit the latest version.
- [Release notes](https://github.com/prometheus/client_rust/releases)
- [Changelog](https://github.com/prometheus/client_rust/blob/master/CHANGELOG.md)
- [Commits](prometheus/client_rust@v0.16.0...v0.17.0)

---
updated-dependencies:
- dependency-name: prometheus-client
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

We are already boxing the given object so we might as well pin to
to avoid the `Unpin` trait bound.

…libp2p#2776)

…rBox` (libp2p#2775)

`StreamMuxerBox` is never shared across threads but owned by a single
connection. Restricting it to be `Sync` unnecessarily limits the design
space around the `StreamMuxer` trait and its implementations.

…iple-endpoints-2

…ibp2p#2765)

Co-authored-by: Elena Frank <elena.frank@protonmail.com>
Co-authored-by: Max Inden <mail@max-inden.de>

Discussed in libp2p#2722.

Generate `NetworkBehaviour::OutEvent` if not provided through
`#[behaviour(out_event = "MyOutEvent")]` and event processing is
disabled (default).

…2p#2800)

…libp2p#2802)

…p#2805)

…2816)

…ibp2p#2797)

This is to allow general-purpose background work to be performed
by implementations.

)

In preparation for libp2p#2751.

* build(deps): Update prost-build requirement from 0.10 to 0.11

Updates the requirements on [prost-build](https://github.com/tokio-rs/prost) to permit the latest version.
- [Release notes](https://github.com/tokio-rs/prost/releases)
- [Commits](tokio-rs/prost@v0.10.0...v0.11.0)

---
updated-dependencies:
- dependency-name: prost-build
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

* build(deps): Update prost requirement from 0.10 to 0.11

Updates the requirements on [prost](https://github.com/tokio-rs/prost) to permit the latest version.
- [Release notes](https://github.com/tokio-rs/prost/releases)
- [Commits](tokio-rs/prost@v0.10.0...v0.11.0)

---
updated-dependencies:
- dependency-name: prost
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Test that `HandlerWrapper` upholds the provided
`max_negotiating_inbound_streams` limit.

…ibp2p#2819)

When generating the `OutEvent` for a `NetworkBehaviour`, add the `where` clause of the
`NetworkBehaviour` `struct` to the generated `enum`.

….0 (libp2p#2822)

* build(deps): Update prometheus-client requirement from 0.17.0 to 0.18.0

Updates the requirements on [prometheus-client](https://github.com/prometheus/client_rust) to permit the latest version.
- [Release notes](https://github.com/prometheus/client_rust/releases)
- [Changelog](https://github.com/prometheus/client_rust/blob/master/CHANGELOG.md)
- [Commits](prometheus/client_rust@v0.17.0...v0.18.0)

---
updated-dependencies:
- dependency-name: prometheus-client
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

When generating an `OutEvent` `enum` definition for a user, derive `Debug`
for that `enum`.

Why not derive `Clone`, `PartialEq` and `Eq` for the generated `enum`
definition?

While it is fine to require all sub-`OutEvent`s to implement
`Debug`, the same does not apply to traits like `Clone`. I
suggest users that need `Clone` to define their own `OutEvent`.

Add document outlining a set of coding guidelines followed and to be
followed across the rust-libp2p code base.

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>

…2827)

When using channels (e.g. `futures::channel::mpsc` or `std::sync::mpsc`)
always use the bounded variant, never use the unbounded variant. When
using a bounded channel, a slow consumer eventually slows down a fast
producer once the channel bound is reached, ideally granting the slow
consumer more system resources e.g. CPU time, keeping queues small and
thus latencies low.  When using an unbounded channel a fast producer
continues being a fast producer, growing the channel buffer
indefinitely, increasing latency until the illusion of unboundedness
breaks and the system runs out of memory.

One may use an unbounded channel if one enforces backpressure through an
out-of-band mechanism, e.g. the consumer granting the producer
send-tokens through a side-channel.

When sending a message to the background task, don't use the
`SinkExt::send` future since this requires static ownership of the
channel sender. Instead use `Sink::poll_ready` and `Sink::start_send`,
which allows us to inline the sending of messages into our poll
functions.
With this we don't need the Mutex around `to_endpoint` anymore. The
background task, the transport, and each connections owns exactly one
`Sender`, thus we don't have unbounded growth here.

* build(deps): Update p256 requirement from 0.10.0 to 0.11.0

Updates the requirements on [p256](https://github.com/RustCrypto/elliptic-curves) to permit the latest version.
- [Release notes](https://github.com/RustCrypto/elliptic-curves/releases)
- [Commits](https://github.com/RustCrypto/elliptic-curves/commits/p256/v0.10.1)

---
updated-dependencies:
- dependency-name: p256
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

* core/: Bump version and add changelog entry

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Max Inden <mail@max-inden.de>

…2p#2840)

Removes the `NetworkBehaviourEventProcess` and all its associated logic.

See deprecation pull request libp2p#2784.

Find rational in libp2p#2751.

Add guideline to limit number of tasks being spawned.

With the removal of `NetworkBehaviourEventProcess` there is no more need for a
custom poll method.

)

With the removal of `NetworkBehaviourEventProcess` there is no more need for
ignoring fields.

libp2p#2817)

…go-deny` (libp2p#2803)

…ime (libp2p#2748)

Allow users to choose between async-io and tokio runtime
in the mdns protocol implementation. `async-io` is a default
feature, with an additional `tokio` feature.

Fix high CPU usage with Tokio library.

Add support for multiple Kademlia protocol names to allow
protocol name upgrades.

Ignoring certain revisions helps in finding the "correct" commit
that touched a file last.

For more information, see:

https://www.git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt

…to<TopicHash>` (libp2p#2862)

Adds two workflows on push & PR:

* `run-ping-interop-cross-version`: runs a Testground interoperability test
  between multiple versions of rust-libp2p, including master, and the current
  branch (during a pull request)
* `run-ping-interop-cross-implementation`: runs a Testground interoperability
  test between go-libp2p and rust-libp2p, and the current branch (during a pull
  request)

We rely on the https://github.com/libp2p/test-plans/ repository to retrieve and
run the tests.

Co-authored-by: Piotr Galar <piotr.galar@gmail.com>

…p#2860)

- Introduce `rsa` feature flag to `libp2p-core`.
- Expose `rsa` feature in `libp2p`.
- Add `rsa` feature to `libp2p` `default`.

See corresponding change in tcp transport: libp2p#2813.

With if-watch `2.0.0` `IfWatcher::new` is not async anymore, hence the
`IfWatch` wrapping logic is obsolete.

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>

In case we accidentally generate the same port twice, we will try to
issue two dial attempts to the same address but also expect two dial
errors which is exactly what this test is trying to catch.
Unfortunately, the assertion is badly written and does not catch
duplicate inputs.

…X25519 DH key exchange (libp2p#2887)

Co-authored-by: Max Inden <mail@max-inden.de>

This patch fixes an issue where we couldn't use type parameters on a behaviour
with a custom out event that had different type parameters.

The existing implementation was based on an old API of the quinn_proto
Endpoint which by now has changed. In particular we can not explicitly
`accept` new connections on the endpoint anymore.
Instead if there is a new connections and our channel for new
connections is full because the endpoint is too busy, we now simply
drop the connection to backpressure the remote.