feat: add a flag for stage1->stage2 validium migration

[dimazhornyk]

What ❔

Introduce an inclusion_verification_transition_enabled flag, which is necessary for enabling inclusion verification in Validiums.
When this flag is used - da_dispatcher only populates the older batches with dummy proofs, and stops polling for inclusion data for new batches.

The migration would look like this:

• A chain is running with use_dummy_inclusion_data: true
• The following values are updated:

da_dispatcher:
  use_dummy_inclusion_data: false
  inclusion_verification_transition_enabled: true
l2:
  da_validator_addr: REAL_VALIDATOR_ADDR

• Some period to commit all old batches
• Set inclusion_verification_transition_enabled: false

As a side-quest: a check whether dummy inclusion proofs are allowed was added.

Why ❔

To ensure that the migration can be performed without downtime.

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.
• Code has been formatted via zkstack dev fmt and zkstack dev lint.

[slowli]

Dumb question: Is it checked somewhere before that the address is not None? If not, it could make sense to use .expect(_) / .context(_) with a descriptive message, so that the error can be debugged. Also, I'm not entirely sure that panicking would be user-friendly; optimally, errors should be propagated as anyhow::Errors to the component task boundary (i.e., DataAvailabilityDispatcher::run() in this case).

[dimazhornyk]

makes sense, added .context(_)
on the second point, totally agree in general, but in this specific context poll_for_inclusion's errors are only logged in run function without propagating them further, so it would be quite a mess with all .map_err() that would need to be added in poll_for_inclusion to make it propagatable

we can also add a check that the l2_da_validator_addr is present to check_for_misconfiguration, though it doesn't remove the need to use unwrap

[slowli]

Nit: Is there a difference with defining inclusion_verification_transition_enabled: bool and slapping #[serde(default)] on it / slightly changing the Protobuf conversion logic? From the type perspective, it looks easier, and in the new config system (that I hope we will use eventually 🙃), a simpler type would mean better auto-generated docs / validations.

[dimazhornyk]

I mostly did it like that to keep in line with the other fields in this config, IMO it would be even worse if some fields were Optional with a getter and the others had #[serde(default)]

I would even consider adding #[serde(default)] to all of them and removing Optional, but maybe it makes sense to do it as a part of a migration to the new config system