doc: Remove some sections from the documentation

CONTRIBUTING.md

@@ -21,7 +21,7 @@ git clone https://github.com/microsoft/vcpkg
 From the root of the repository run:
 
 ```sh
-# Make sure the VCPKG_ROOT env variable points to the to the cloned vcpkg repository
+# Make sure the VCPKG_ROOT env variable points to the cloned vcpkg repository
 cmake --preset default
 ```
 

README.md

@@ -354,14 +354,3 @@ Check out the [examples](/example) and the [documentation](https://tradias.githu
 
 </p>
 </details>
-
-
-# What users are saying
-
-> Asio-grpc abstracts away the implementation details of asynchronous grpc handling: crafting working code is easier, faster, less prone to errors and considerably more fun. At 3YOURMIND we reliably use asio-grpc in production since its very first release, allowing our developers to effortlessly implement low-latency/high-throughput asynchronous data transfer in time critical applications.
-
-[@3YOURMIND](https://github.com/3YOURMIND)
-
-> Our project is a real-time distributed motion capture system that uses your framework to stream data back and forward between multiple machines. Previously I have tried to build a bidirectional streaming framework from scratch using only gRPC. However, it's not maintainable and error-prone due to a large amount of service and streaming code. As a developer whose experienced both raw grpc and asio-grpc, I can tell that your framework is a real a game-changer for writing grpc code in C++. It has made my life much easier. I really appreciate the effort you have put into this project and your superior skills in designing c++ template code.
-
-[@khanhha](https://github.com/khanhha)

doc/difference_to_asio.md

@@ -1,6 +1,8 @@
 # Difference to Asio
 
-The free functions in this library (except `agrpc::repeatedly_request`) require that the completion handler's executor be created from a `agrpc::GrpcExecutor` and they use that as the I/O executor. Unlike Asio, where the I/O executor is obtained from the first argument to the initiating function. Example:
+Asio-grpc strives to adhere to asio's asynchronous model as closely as possible. However, some parts of asio-grpc's older API deviate from that model. The exact differences are described below.
+
+The free functions in this library (except those that take a GrpcContext/GrpcExecutor as their first argument) require that the completion handler's executor be created from a `agrpc::GrpcExecutor` and they use that as the I/O executor. Unlike Asio, where the I/O executor is obtained from the first argument to the initiating function. Example:
 
 ```cpp
 asio::steady_timer timer{exec1}; // exec1 is the I/O executor
@@ -17,20 +19,9 @@ agrpc::wait(alarm, deadline, asio::bind_executor(grpc_context.get_executor(), []
 
 As a consequence, the asynchronous operations always complete in the thread that called `GrpcContext::run*()/poll*()`, whereas Asio would submit the completion handler for execution as if by performing `asio::dispatch(exec2, [=<moved>]() { completion_handler(args...); })`. See also [Asio's documentation](https://www.boost.org/doc/libs/1_79_0/doc/html/boost_asio/reference/asynchronous_operations.html).
 
-All classes documented as "I/O object" in asio-grpc behave more closely to Asio and perform the dispatch and do not require the completion handler's executor be created from a `agrpc::GrpcExecutor`.
-
--------
-
-Until asio-grpc v2.0.0 the completion handler's allocator was retrieved in a manner equivalent to:
+More recently added APIs like the `agrpc::Alarm` behave exactly like Asio:
 
 ```cpp
-asio::get_associated_allocator(completion_handler, asio::query(asio::get_associated_executor(completion_handler), asio::execution::allocator));
-```
-
-Since v2.0.0 the allocator is retrieved using:
-
-```cpp
-asio::get_associated_allocator(completion_handler);
-```
-
-which is equivalent to Asio.
+agrpc::Alarm alarm{grpc_context} // grpc_context.get_executor() is the I/O executor
+alarm.wait(100ms, asio::bind_executor(exec2, [](auto&&) {})); // exec2 is the completion handler executor
+```

doc/rpc_cheat_sheet.md

@@ -12,9 +12,9 @@ must have an associated executor that refers to a GrpcContext:
 
 ## Client
 
-**Since asio-grpc v2.1.0, the recommended gRPC client API is `agrpc::RPC`. It provides a customizable default completion token and always uses the correct associated executor. The old, low-level API is documented below.**
+**Since asio-grpc v2.1.0, the recommended gRPC client API is `agrpc::RPC`. It provides a customizable default completion token and always uses the correct I/O executor. The old, low-level API is documented below.**
 
-All RPC types support retrieving initial metadata immediately. This is optional step. Completes with `false` if the call is dead.
+All RPC types support retrieving initial metadata immediately. This step is optional. It completes with `false` if the call is dead.
 
 @snippet client.cpp read_initial_metadata-unary-client-side
 
@@ -36,7 +36,7 @@ All RPC types support retrieving initial metadata immediately. This is optional
 
 ## Server
 
-All RPC types support sending initial metadata immediately. This is optional step. Completes with `false` if the call is dead.
+All RPC types support sending initial metadata immediately. This step is optional. It completes with `false` if the call is dead.
 
 @snippet server.cpp send_initial_metadata-unary-server-side