load da_committee from genesis file

[pls148]

This PR:

• Adds support for genesis -> da_committees
• Parsing of da_committees
• EpochCommittees now holds da_committees as data instead of known_da_nodes

This PR does not:

• Actually do anything with the new data

Key places to review:

Example da_committees in data/genesis/X.toml:

[da_committees]
0.3 = {
    0 = [
        { stake_table_key = "BLS_VER_KEY~bQszS-QKYvUij2g20VqS8asttGSb95NrTu2PUj0uMh1CBUxNy1FqyPDjZqB29M7ZbjWqj79QkEOWkpga84AmDYUeTuWmy-0P1AdKHD3ehc-dKvei78BDj5USwXPJiDUlCxvYs_9rWYhagaq-5_LXENr78xel17spftNd5MA1Mw5U", state_ver_key = "SCHNORR_VER_KEY~lJqDaVZyM0hWP2Br52IX5FeE-dCAIC-dPX7bL5-qUx-vjbunwe-ENOeZxj6FuOyvDCFzoGeP7yZ0fM995qF-CRE", stake = 1 }
    ]
}

[ss-es]

I think this could be an error

or arguably even a panic -- I think it might be preferable to call this a misconfiguration and immediately panic vs. try to resolve the ambiguity

[ss-es]

or_default means return an empty vec here right? I think it would be better to panic, since an empty DA committee is always a (fatal) error

[ss-es]

A BTreeMap can be null right? do we need to make this an Option?

[ss-es]

also is there a reason it needs to be in both HotShotConfig and Genesis?

do we use it out of HotShotConfig anywhere? (I think it's fine to leave it in both even if we only use it out of genesis, just wondering)

[ss-es]

I think the inner BTreeMap is unnecessary -- this should just be a BTreeMap<Version, (u64, PeerConfig<SeqTypes>)>

maybe @bfish713 can comment, but I think it's unlikely that we'd schedule an upgrade with multiple DA committees that take effect at different points in the future? and it definitely complicates the logic