fix: upgrade Docusaurus from 2.0.0-beta to 3.9.2 to resolve all security vulnerabilities

Upgrade all three workspaces (website, doc, blog) from Docusaurus
2.0.0-beta.6/beta.8 to 3.9.2. This resolves all 1,605 npm audit
vulnerabilities (now 0).

Major changes:
- Migrate all docusaurus.config.js files to v3 format
- Fix 17 blog posts (en + zh) with MDX v3 incompatible syntax
- Delete obsolete v2 swizzled components (DocPage, DocSidebar,
  SearchBar, CodeBlock) and replace with v3 equivalents
- Migrate all v2-only theme APIs to v3 counterparts
- Update CI workflows from Node 12/16 to Node 18
- Remove unused dependencies (patch-package, swiper)
- Add serialize-javascript resolution to fix transitive vulnerability
- Delete all patch-package patches (no longer needed with v3)
- Update tsconfig.json files for Docusaurus 3 compatibility

Author: Baoyuantop

.github/workflows/deploy.yml

@@ -33,7 +33,7 @@ jobs:
 
       - uses: actions/setup-node@v3
         with:
-          node-version: '16'
+          node-version: '18'
 
       - name: Get node version
         id: node-version

.github/workflows/link-check.yml

@@ -26,7 +26,7 @@ jobs:
       - uses: actions/checkout@v3.1.0
       - uses: actions/setup-node@v3
         with:
-          node-version: "16"
+          node-version: "18"
 
       - name: Install Dependencies
         run: |

.github/workflows/lint.yml

@@ -11,7 +11,7 @@ jobs:
       - name: 🚀 Use Node.js
         uses: actions/setup-node@v3
         with:
-          node-version: '12.x'
+          node-version: '18'
       - run: npm install -g markdownlint-cli@0.25.0
       - run: markdownlint '**/*.md' --ignore node_modules
   yamllint:

blog/en/blog/2021/07/14/the-road-to-customization-of-Sina-Weibo-API-gateway-based-on-Apache-APISIX.md

@@ -110,7 +110,7 @@ The full canary release feature requires some API support exposed on the gateway
 
 ![Support Canary Release3](https://static.apiseven.com/202108/1646900211377-0c1df098-c5be-4c69-bda6-eabd1518f0f5.png)
 
-Canary release API fixed URI, the unified path is /admin/services/gray/{SAAS_ID}/ routes. Different HTTP Method presents different business meanings, POST means create, DELETE means to stop canary release, GET means to view.
+Canary release API fixed URI, the unified path is `/admin/services/gray/{SAAS_ID}/` routes. Different HTTP Method presents different business meanings, POST means create, DELETE means to stop canary release, GET means to view.
 
 #### Activation Process
 

blog/en/blog/2021/08/10/apisix-nginx.md

@@ -53,7 +53,7 @@ etcd:
   prefix: /apisix # apisix configurations prefix
 ```
 
-and upstreams/1 is equivalent to http { upstream 1 {} } in nginx.conf. Similar keywords are used in /apisix/services/, /apisix/routes/, and so on.
+and upstreams/1 is equivalent to http \{ upstream 1 \{\} \} in nginx.conf. Similar keywords are used in /apisix/services/, /apisix/routes/, and so on.
 
 So, how does Nginx get the etcd configuration data changes through the watch mechanism? Does it start a new agent process? Does it communicate with etcd via HTTP/1.1 or gRPC?
 

blog/en/blog/2021/08/16/Using-the-Apache-APISIX-OpenID-Connect-Plugin-for-Centralized-Authentication.md

@@ -94,9 +94,9 @@ Have an Okta account ready for use.
    ![save the changes](https://static.apiseven.com/202108/1639467449049-628d7796-0d8e-4ed9-8334-5ba7f0fb32f4.png)
 5. Visit the General page of the application to obtain the following configuration, which is required to configure Apache APISIX OpenID Connect.
 
-- Client ID: OAuth client ID, the application ID, which corresponds to client_id and {YOUR_CLIENT_ID} below.
-- Client secret: OAuth client secret, the application key, which corresponds to client_secret and {YOUR_CLIENT_SECRET} below.
-- Okta domain: The domain name used by the application, corresponding to {YOUR_ISSUER} below.
+- Client ID: OAuth client ID, the application ID, which corresponds to client_id and `{YOUR_CLIENT_ID}` below.
+- Client secret: OAuth client secret, the application key, which corresponds to client_secret and `{YOUR_CLIENT_SECRET}` below.
+- Okta domain: The domain name used by the application, corresponding to `{YOUR_ISSUER}` below.
 
 ![obtain configuration](https://static.apiseven.com/202108/1639467501106-d95bf8ad-db47-4918-ac70-424b12488e5b.png)
 

blog/en/blog/2021/12/08/apisix-integrate-rocketmq-logger-plugin.md

@@ -104,7 +104,7 @@ The first thing you can do is to adjust the relevant log format in the form of a
 
 | Name             |  Default Value |  Description                                             |
 | ---------------- |  ------------- | ------------------------------------------------ |
-| log_format       |  {"host": "$host", "@timestamp": "$time_iso8601", "client_ip": "$remote_addr"} |    Declare the log format as a key-value pair in JSON format. For the value section, only strings are supported. If it starts with `$`, it indicates that you want to get the __APISIX__ variable or [Nginx built-in variable](http://nginx.org/en/docs/varindex.html). In particular, __this setting takes effect globally__, which means that when log_format is specified, it will take effect on all Route or Service bound to http-logger. |
+| log_format       |  `{"host": "$host", "@timestamp": "$time_iso8601", "client_ip": "$remote_addr"}` |    Declare the log format as a key-value pair in JSON format. For the value section, only strings are supported. If it starts with `$`, it indicates that you want to get the __APISIX__ variable or [Nginx built-in variable](http://nginx.org/en/docs/varindex.html). In particular, __this setting takes effect globally__, which means that when log_format is specified, it will take effect on all Route or Service bound to http-logger. |
 
 Once the log format is adjusted, you need to send a request to the `/apisix/admin/plugin_metadata` endpoint to update the metadata, as described in the code below.
 

blog/en/blog/2021/12/22/google-logging.md

@@ -146,7 +146,7 @@ curl http://127.0.0.1:9080/apisix/admin/routes/1  -H 'X-API-KEY: edd1c9f034335f1
 |auth_config.scopes|No|["https://www.googleapis.com/auth/logging.read","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/logging.admin","https://www.googleapis.com/auth/cloud-platform"]|Google Services account access scope, refer to: [OAuth 2.0 Scopes for Google APIs](https://developers.google.com/identity/protocols/oauth2/scopes#logging)|
 |auth_file|No|n/a|Path to the Google Services account JSON file (either auth_config or auth_file must be configured)|
 |ssl_verify|No|TRUE|Enable SSL authentication, configured according to [OpenResty documentation](https://github.com/openresty/lua-nginx-module#tcpsocksslhandshake) options.|
-|resource|No|{"type": "global"}|Google Monitored Resources, please refer to [MonitoredResource](https://cloud.google.com/logging/docs/reference/v2/rest/v2/MonitoredResource).|
+|resource|No|`{"type": "global"}`|Google Monitored Resources, please refer to [MonitoredResource](https://cloud.google.com/logging/docs/reference/v2/rest/v2/MonitoredResource).|
 |log_id|No|apisix.apache.org%2Flogs|Google Log ID, reference: [LogEntry](https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry).|
 |max_retry_count|No|0|Maximum number of retries before removal from the processing pipeline.|
 |retry_delay|No|1|Number of seconds that process execution should be delayed if execution fails.|

blog/en/blog/2022/07/06/use-keycloak-with-api-gateway-to-secure-apis.md

@@ -273,7 +273,7 @@ Because APISIX writes `id_token`, `access_token`, and `refresh_token` into the c
 2. **How to change the name and location of the cookie stored in the Session?**
 
 Currently, the openid-connect plugin does not provide the ability to customize this part of the configuration, so we can use the method provided in `lua-resty-session`: override its default configuration by NGINX variables.
-We rely on the NGINX configuration injection capabilities provided by APISIX to achieve the override: the name of the Session storage cookie can be modified by adding this code to the configuration file {apisix}/conf/config.yaml.
+We rely on the NGINX configuration injection capabilities provided by APISIX to achieve the override: the name of the Session storage cookie can be modified by adding this code to the configuration file `{apisix}/conf/config.yaml`.
 
 ```yaml
 nginx_config:

blog/en/blog/2023/01/02/accessing_apisix-dashboard_from_everywhere_with_keycloak_authentication.md

@@ -644,7 +644,7 @@ Forwarding from 127.0.0.1:8080 -> 9000
 Forwarding from [::1]:8080 -> 9000
 ```
 
-Then access the dashboard on **“hdev”** pointing the web browser to the url “http://localhost:9090”
+Then access the dashboard on **“hdev”** pointing the web browser to the url `http://localhost:9090`
 Login with **“admin / admin”**
 
 ![ad01](https://static.apiseven.com/uploads/2023/01/20/INeavn6G_8%20ad01.png)
@@ -889,7 +889,7 @@ Access “https://apisix.h.net” from a browser. You should receive page not fo
 
 > Work on **hdev**
 
-port forward apisix-dashboard and access it at “http://localhost:9090” and login with **“admin” / "admin“**
+port forward apisix-dashboard and access it at `http://localhost:9090` and login with **“admin” / "admin“**
 
 ```
 kubectl -n apisix port-forward service/apisix-dashboard 9090:80
@@ -960,7 +960,7 @@ sysop@hserv:~/H$ rsync -vau --stats ./hservcerts/* hdev.int.h.net://home/sysop/H
 
 > Work on **hdev**
 
-Port forward apisix-dashboard and access it ah “http://localhost:9090” and login with **“admin” / "admin“**
+Port forward apisix-dashboard and access it ah `http://localhost:9090` and login with **“admin” / "admin“**
 
 ```
 kubectl -n apisix port-forward service/apisix-dashboard 9090:80