feat: add Electra support to beacon bridge

[morph-dev]

This is a followup of #1801

What was wrong?

Beacon bridge doesn't support creating and gossiping Electra Beacon types.

How was it fixed?

Added support for gossiping content across forks.

I refactored how we are decoding ssz content that we receive from consensus_api to be fork aware.

To-Do

• Clean up commit history and use conventional commits.

[KolbyML]

diff --git a/bin/portal-bridge/src/api/consensus/mod.rs b/bin/portal-bridge/src/api/consensus/mod.rs
index da050f41..012439e3 100644
--- a/bin/portal-bridge/src/api/consensus/mod.rs
+++ b/bin/portal-bridge/src/api/consensus/mod.rs
@@ -45,13 +45,13 @@ impl ConsensusApi {
             "Starting ConsensusApi with primary provider: {primary} and fallback provider: {fallback}",
         );
         let primary =
-            ClientWithBaseUrl::new(primary, request_timeout, ContentType::Ssz).map_err(|err| {
+            ClientWithBaseUrl::new(primary, request_timeout, ContentType::Json).map_err(|err| {
                 anyhow!("Unable to create primary client for consensus data provider: {err:?}")
             })?;
         if let Err(err) = Self::check_provider(&primary).await {
             warn!("Primary consensus data provider may be offline: {err:?}");
         }
-        let fallback = ClientWithBaseUrl::new(fallback, request_timeout, ContentType::Ssz)
+        let fallback = ClientWithBaseUrl::new(fallback, request_timeout, ContentType::Json)
             .map_err(|err| {
                 anyhow!("Unable to create fallback client for consensus data provider: {err:?}")
             })?;
@@ -290,3 +290,34 @@ impl ConsensusApi {
             .data)
     }
 }
+
+#[tokio::test]
+async fn hi() {
+    use alloy::hex::FromHex;
+    use std::str::FromStr;
+    let api = ConsensusApi::new(
+        Url::from_str("https://nimbus.mainnet.eu1.ethpandaops.io/").unwrap(),
+        Url::from_str("https://nimbus.mainnet.eu1.ethpandaops.io/").unwrap(),
+        90,
+    )
+    .await
+    .unwrap();
+
+    assert!(api.get_beacon_state().await.is_ok());
+    assert!(api.get_node_version().await.is_ok());
+    assert!(api
+        .get_light_client_bootstrap(
+            B256::from_hex("0x51e17921dc1204147a86c5bc229c02894052db8435c63290f93e275c95b2c507")
+                .unwrap()
+        )
+        .await
+        .is_ok());
+    assert!(api
+        .get_light_client_updates(11572384 / (32 * 256), 1)
+        .await
+        .is_ok());
+    assert!(api.get_light_client_optimistic_update().await.is_ok());
+    assert!(api.get_light_client_finality_update().await.is_ok());
+    assert!(api.get_beacon_block_root("head").await.is_ok());
+    assert!(api.get_beacon_state_finalized_root().await.is_ok());
+}

There has been some regressions with this PR. The BeaconAPI can return Json or Ssz we can only tell the provider our priority, but they can return either format back to us.

get_light_client_updates is failing and only has JSON support currently. Other BeaconAPI endpoints we support are failing, if json is returned by the provider.

All the endpoints are working before this PR with

• ssz set as priority
• json set as priority

where applicable, not all endpoints support ssz for example