Teztale: Collect shard assignments from L1 node and push them to server

What

Parent MR: !20049 (merged)

This MR makes the Teztale archiver fetch DAL shard assignments from the L1 node (for protocols that expose the DAL RPC) and push these assignments to the Teztale server via the /\<LEVEL\>/dal_shards endpoint introduced in !20049 (merged).

Why

We want to know which shards each delegate is responsible for at a given level. This allows Teztale to correlate attestations and DAL shard assignments.

How

Steps followed:

• The generic archiver pipeline (general_archiver) queries the per-level DAL shards RPC from the protocol plugin.
• The remote archiver (Server_archiver) sends the resulting per-delegate shard assignments to Teztale at /<LEVEL>/dal_shards.
• For older protocols or networks without DAL, shard collection is a no-op (returns an empty list).

Manually testing the MR

Manual test on ghostnet:

1. I started an L1 node on ghostnet (with the usual steps):

./octez-node run --data-dir ~/.tezos-node-ghostnet --rpc-addr 127.0.0.1:18733 --net-addr 127.0.0.1:19733

and waited for it to be bootstrapped.

2. I started a Teztale server

./octez-teztale-server ./teztale.json

3. I started a Teztale archiver to feed data from the L1 node to the server:

./octez-teztale-archiver --endpoint http://127.0.0.1:18733 feed http://gabriel:secret@127.0.0.1:8080

4. I checked the Teztale DB:

sqlite3 teztale.db "                                                  
  SELECT
    s.id,
    er.level,
    hex(d.address) AS delegate_hex,
    s.shard_index
  FROM dal_shard_assignments AS s
  JOIN endorsing_rights       AS er ON er.id = s.endorsing_right
  JOIN delegates              AS d  ON d.id = er.delegate
  ORDER BY er.level, s.id
  LIMIT 10;
"

1|16585025|02C6077B3BACD58DB19933093E105709F44FE8E0B2|183
2|16585025|02B4E7026109CB35639998FEBF973E3284DC013020|6
3|16585025|02AA9F6016DDE8C8ACE33CE5C7B709019B0130B816|67
4|16585025|02AA9F6016DDE8C8ACE33CE5C7B709019B0130B816|196
5|16585025|02AA9F6016DDE8C8ACE33CE5C7B709019B0130B816|441
6|16585025|0266A20528EFAF41C6BBDB80750DCF6494DA19EAE4|48
7|16585025|0266A20528EFAF41C6BBDB80750DCF6494DA19EAE4|80
8|16585025|0266A20528EFAF41C6BBDB80750DCF6494DA19EAE4|96
9|16585025|0266A20528EFAF41C6BBDB80750DCF6494DA19EAE4|181
10|16585025|0266A20528EFAF41C6BBDB80750DCF6494DA19EAE4|216

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR