Update stale sections of the book (sigp#3671)

## Issue Addressed

Which issue # does this PR address?

## Proposed Changes

* Add v3.2 and v3.3 to database migrations table
* Remove docs on `--subscribe-all-subnets` and `--import-all-attestations` from redundancy docs
* Clarify that the merge has already occurred on the merge migration page

book/src/database-migrations.md

@@ -24,6 +24,8 @@ validator client or the slasher**.
 | v2.5.0             | Aug 2022     | v11            | yes                  |
 | v3.0.0             | Aug 2022     | v11            | yes                  |
 | v3.1.0             | Sep 2022     | v12            | yes                  |
+| v3.2.0             | Oct 2022     | v12            | yes                  |
+| v3.3.0             | TBD          | v13            | yes                  |
 
 > **Note**: All point releases (e.g. v2.3.1) are schema-compatible with the prior minor release
 > (e.g. v2.3.0).

book/src/merge-migration.md

@@ -1,9 +1,8 @@
 # Merge Migration
 
-This document provides detail for users who want to run a merge-ready Lighthouse node.
+This document provides detail for users who want to run a Lighthouse node on post-merge Ethereum.
 
-> The merge is occurring on mainnet in September. You _must_ have a merge-ready setup by September 6
-> 2022.
+> The merge occurred on mainnet in September 2022.
 
 ## Necessary Configuration
 
@@ -27,12 +26,9 @@ engine to a merge-ready version.
 You must configure your node to be merge-ready before the Bellatrix fork occurs on the network
 on which your node is operating.
 
-* **Mainnet**: the Bellatrix fork is scheduled for epoch 144896, September 6 2022 11:34 UTC.
-  You must ensure your node configuration is updated before then in order to continue following
-  the chain. We recommend updating your configuration now.
-
-* **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**: the Bellatrix fork has already occurred.
-  You must have a merge-ready configuration right now.
+* **Gnosis**: the Bellatrix fork has not yet been scheduled.
+* **Mainnet**, **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**: the Bellatrix fork has
+  already occurred. You must have a merge-ready configuration right now.
 
 ## Connecting to an execution engine
 

book/src/redundancy.md

@@ -55,42 +55,27 @@ In our previous example, we listed `http://192.168.1.1:5052` as a redundant
 node. Apart from having sufficient resources, the backup node should have the
 following flags:
 
-- `--staking`: starts the HTTP API server and ensures the execution chain is synced.
+- `--http`: starts the HTTP API server.
 - `--http-address 0.0.0.0`: this allows *any* external IP address to access the
 	HTTP server (a firewall should be configured to deny unauthorized access to port
 	`5052`). This is only required if your backup node is on a different host.
-- `--subscribe-all-subnets`: ensures that the beacon node subscribes to *all*
-	subnets, not just on-demand requests from validators.
-- `--import-all-attestations`: ensures that the beacon node performs
-	aggregation on all seen attestations.
+- `--execution-endpoint`: see [Merge Migration](./merge-migration.md).
+- `--execution-jwt`: see [Merge Migration](./merge-migration.md).
 
-Subsequently, one could use the following command to provide a backup beacon
-node:
+For example one could use the following command to provide a backup beacon node:
 
 ```bash
 lighthouse bn \
-  --staking \
+  --http \
   --http-address 0.0.0.0 \
-  --subscribe-all-subnets \
-  --import-all-attestations
+  --execution-endpoint http://localhost:8551 \
+  --execution-jwt /secrets/jwt.hex
 ```
 
-### Resource usage of redundant Beacon Nodes
-
-The `--subscribe-all-subnets` and `--import-all-attestations` flags typically
-cause a significant increase in resource consumption. A doubling in CPU
-utilization and RAM consumption is expected.
-
-The increase in resource consumption is due to the fact that the beacon node is
-now processing, validating, aggregating and forwarding *all* attestations,
-whereas previously it was likely only doing a fraction of this work. Without
-these flags, subscription to attestation subnets and aggregation of
-attestations is only performed for validators which [explicitly request
-subscriptions][subscribe-api].
-
-There are 64 subnets and each validator will result in a subscription to *at
-least* one subnet. So, using the two aforementioned flags will result in
-resource consumption akin to running 64+ validators.
+Prior to v3.2.0 fallback beacon nodes also required the `--subscribe-all-subnets` and
+`--import-all-attestations` flags. These flags are no longer required as the validator client will
+now broadcast subscriptions to all connected beacon nodes by default. This broadcast behaviour
+can be disabled using the `--disable-run-on-all` flag for `lighthouse vc`.
 
 ## Redundant execution nodes