document early_request_filter

Fix #363
---
updated

Includes-commit: 204ddb0
Includes-commit: 34c67f0
Replicated-from: #368
Signed-off-by: spacewander <spacewanderlzx@gmail.com>

.bleep

@@ -1 +1 @@
-265d5245705c6f762c7dd37536f9d1c61d2d8af9
+6923a7f31ed6fff1ddaf00ffb8dd56311042c395

docs/user_guide/phase.md

@@ -16,7 +16,8 @@ The pingora-proxy HTTP proxy framework supports highly programmable proxy behavi
 Pingora-proxy allows users to insert arbitrary logic into the life of a request.
 ```mermaid
  graph TD;
-    start("new request")-->request_filter;
+    start("new request")-->early_request_filter;
+    early_request_filter-->request_filter;
     request_filter-->upstream_peer;
 
     upstream_peer-->Connect{{IO: connect to upstream}};
@@ -52,9 +53,12 @@ Pingora-proxy allows users to insert arbitrary logic into the life of a request.
 * The reason both `upstream_response_*_filter()` and `response_*_filter()` exist is for HTTP caching integration reasons (still WIP).
 
 
-### `request_filter()`
+### `early_request_filter()`
 This is the first phase of every request.
 
+This function is similar to `request_filter()` but executes before any other logic, including downstream module logic. The main purpose of this function is to provide finer-grained control of the behavior of the modules.
+
+### `request_filter()`
 This phase is usually for validating request inputs, rate limiting, and initializing context.
 
 ### `proxy_upstream_filter()`

docs/user_guide/phase_chart.md

@@ -1,7 +1,8 @@
 Pingora proxy phases without caching
 ```mermaid
  graph TD;
-    start("new request")-->request_filter;
+    start("new request")-->early_request_filter;
+    early_request_filter-->request_filter;
     request_filter-->upstream_peer;
 
     upstream_peer-->Connect{{IO: connect to upstream}};

pingora-proxy/src/proxy_trait.rs

@@ -69,9 +69,9 @@ pub trait ProxyHttp {
 
     /// Handle the incoming request before any downstream module is executed.
     ///
-    /// This function is similar to [Self::request_filter()] but execute before any other logic
-    /// especially the downstream modules. The main purpose of this function is to provide finer
-    /// grained control of behavior of the modules.
+    /// This function is similar to [Self::request_filter()] but executes before any other logic,
+    /// including downstream module logic. The main purpose of this function is to provide finer
+    /// grained control of the behavior of the modules.
     ///
     /// Note that because this function is executed before any module that might provide access
     /// control or rate limiting, logic should stay in request_filter() if it can in order to be