Remove Portal beacon-lc-bridge (#2897)

The idea of the beacon-lc-bridge was to allow to bridge data into
the Portal network while only using p2p protocols to get access
to the data.

It is however incomplete as for history content the receipts are
missing. These could be added by also adding devp2p access.
But for the beacon content, there would be no way for getting the
historical summaries over p2p.

And then we did not even look yet on how to do this for state.

Considering it is incomplete it was also not being used by anyone
and thus we remove it.

Makefile

@@ -71,13 +71,11 @@ TOOLS_CSV := $(subst $(SPACE),$(COMMA),$(TOOLS))
 # Fluffy debugging tools + testing tools
 FLUFFY_TOOLS := \
 	portal_bridge \
-	beacon_lc_bridge \
 	eth_data_exporter \
 	blockwalk \
 	portalcli \
 	fcli_db
 FLUFFY_TOOLS_DIRS := \
-	fluffy/tools/beacon_lc_bridge \
 	fluffy/tools/portal_bridge \
 	fluffy/tools/state_bridge \
 	fluffy/tools

fluffy/docs/the_fluffy_book/docs/history-content-bridging.md

@@ -1,14 +1,12 @@
 # Bridging content into the Portal history network
 
-## Seeding from content bridges
-
-### Seeding history content with the `portal_bridge`
+## Seeding history content with the `portal_bridge`
 
 The `portal_bridge` requires `era1` files as source for the block content from before the merge.
 It requires access to a full node with EL JSON-RPC API for seeding the latest (head of the chain) block content.
 Any block content between the merge and the latest is currently not implemented, but will be implemented in the future by usage of `era` files as source.
 
-#### Step 1: Run a Portal client
+### Step 1: Run a Portal client
 
 Run a Portal client with the Portal JSON-RPC API enabled, e.g. Fluffy:
 
@@ -20,12 +18,12 @@ Run a Portal client with the Portal JSON-RPC API enabled, e.g. Fluffy:
 for the use case where the node's only focus is on gossiping content from the
 `portal_bridge`.
 
-#### Step 2: Run an EL client
+### Step 2: Run an EL client
 
 The `portal_bridge` needs access to the EL JSON-RPC API, either through a local
 Ethereum client or via a web3 provider.
 
-#### Step 3: Run the Portal bridge in history mode
+### Step 3: Run the Portal bridge in history mode
 
 Build & run the `portal_bridge`:
 ```bash
@@ -49,33 +47,6 @@ WEB3_URL="http://127.0.0.1:8548" # Replace with your provider.
 ./build/portal_bridge history --latest:true --backfill:true --audit:true --era1-dir:/somedir/era1/ --web3-url:${WEB3_URL}
 ```
 
-### Seeding post-merge history content with the `beacon_lc_bridge`
-
-The `beacon_lc_bridge` is more of a standalone bridge that does not require access to a full node with its EL JSON-RPC API. However it is also more limited in the functions it provides.
-It will start with the consensus light client sync and follow beacon block gossip. Once it is synced, the execution payload of new beacon blocks will be extracted and injected in the Portal network as execution headers
-and blocks.
-
-> Note: The execution headers will come without a proof.
-
-The injection into the Portal network is done via the
-`portal_historyGossip` JSON-RPC endpoint of the running Fluffy node.
-
-> Note: Backfilling of block bodies and headers is not yet supported.
-
-Run a Fluffy node with the JSON-RPC API enabled.
-
-```bash
-./build/fluffy --rpc
-```
-
-Build & run the `beacon_lc_bridge`:
-```bash
-make beacon_lc_bridge
-
-TRUSTED_BLOCK_ROOT=0x1234567890123456789012345678901234567890123456789012345678901234 # Replace with trusted block root.
-./build/beacon_lc_bridge --trusted-block-root=${TRUSTED_BLOCK_ROOT}
-```
-
 ## Seeding directly from the fluffy client
 
 This method currently only supports seeding block content from before the merge.