docs: fix typos

Pull-Request: #4897.

README.md

@@ -42,7 +42,7 @@ The main components of this repository are structured as follows:
 
   * `transports/`: Implementations of transport protocols (e.g. TCP) and protocol upgrades
     (e.g. for authenticated encryption, compression, ...) based on the `libp2p-core` `Transport`
-    API .
+    API.
 
   * `muxers/`: Implementations of the `StreamMuxer` interface of `libp2p-core`,
     e.g. (sub)stream multiplexing protocols on top of (typically TCP) connections.

docs/coding-guidelines.md

@@ -28,7 +28,7 @@ Below is a set of coding guidelines followed across the rust-libp2p code base.
 
 ## Hierarchical State Machines
 
-If you sqint, rust-libp2p is just a big hierarchy of [state
+If you squint, rust-libp2p is just a big hierarchy of [state
 machines](https://en.wikipedia.org/wiki/Finite-state_machine) where parents pass
 events down to their children and children pass events up to their parents.
 
@@ -167,7 +167,7 @@ impl Stream for SomeStateMachine {
 }
 ```
 
-This priotization provides:
+This prioritization provides:
 - Low memory footprint as local queues (here `events_to_return_to_parent`) stay small.
 - Low latency as accepted local work is not stuck in queues.
 - DOS defense as a remote does not control the size of the local queue, nor starves local work with its remote work.
@@ -195,7 +195,7 @@ through a side-channel.
 ### Local queues
 
 As for channels shared across potentially concurrent actors (e.g. future tasks
-or OS threads), the same applies for queues owned by a single actor only. E.g.
+or OS threads), the same applies to queues owned by a single actor only. E.g.
 reading events from a socket into a `Vec<Event>` without some mechanism
 bounding the size of that `Vec<Event>` again can lead to unbounded memory
 growth and high latencies.
@@ -241,7 +241,7 @@ shows a speed up when running it concurrently.
 ## Use `async/await` for sequential execution only
 
 Using `async/await` for sequential execution makes things significantly simpler.
-Though unfortunately using `async/await` does not allow accesing methods on the
+Though unfortunately using `async/await` does not allow accessing methods on the
 object being `await`ed unless paired with some synchronization mechanism like an
 `Arc<Mutex<_>>`.
 
@@ -308,7 +308,7 @@ response and a previous request. For example, if a user requests two new connect
 peer, they should be able to match each new connection to the corresponding previous connection
 request without having to guess.
 
-When accepting a **command** that eventually results in a response through an event require that
+When accepting a **command** that eventually results in a response through an event requires that
 command to contain a unique ID, which is later on contained in the asynchronous response event. One
 such example is the `Swarm` accepting a `ToSwarm::Dial` from the `NetworkBehaviour`.
 

docs/release.md

@@ -65,13 +65,13 @@ Hence, we are going to bump those versions once we work through the milestone th
 
 ## Dealing with alphas
 
-Unfortunately, `cargo` has a rather uninutitive behaviour when it comes to dealing with pre-releases like `0.1.0-alpha`.
+Unfortunately, `cargo` has a rather unintuitive behaviour when it comes to dealing with pre-releases like `0.1.0-alpha`.
 See this internals thread for some context: https://internals.rust-lang.org/t/changing-cargo-semver-compatibility-for-pre-releases
 
 In short, cargo will automatically update from `0.1.0-alpha.1` to `0.1.0-alpha.2` UNLESS you pin the version directly with `=0.1.0-alpha.1`.
 However, from a semver perspective, changes between pre-releases can be breaking.
 
-To avoid accidential breaking changes for our users, we employ the following convention for alpha releases:
+To avoid accidental breaking changes for our users, we employ the following convention for alpha releases:
 
 - For a breaking change in a crate with an alpha release, bump the "minor" version but retain the "alpha" tag.
   Example: `0.1.0-alpha` to `0.2.0-alpha`.