Export state for genesis tinkering

[toliaqat]

The current setup embeds the chain-id within the data folder. To operate the a3p container using an alternate chain-id, users must currently export the state manually and then re-import it after making necessary adjustments. This need arose for me when I attempted to run two separate a3p chains with distinct chain-ids on the same cluster for testing IBC relaying.

This proposed change involves exporting the state to the config folder and removing the data. The concept is that upon startup, the container will initially load the state from the exported genesis, allowing it to function as it previously did. Those who wish to use a different chain-id can simply modify the exported genesis before initiating the chain.

[mhofman]

I'm not sure this should be part of the base image. It's pretty costly to do a genesis export / import, and does not represent the activity that occurred on mainnet.

Is there a reason these steps cannot be performed in a layer on top of the a3p image, e.g. in a separate Dockerfile which uses a3p as a base?

[toliaqat]

I'm not sure this should be part of the base image. It's pretty costly to do a genesis export / import, and does not represent the activity that occurred on mainnet.

Is there a reason these steps cannot be performed in a layer on top of the a3p image, e.g. in a separate Dockerfile which uses a3p as a base?

@mhofman The export only takes time at build time, and the import is less than 5 minutes when the container starts. These 5 minutes could be too much or maybe more depending on the user's machine. The benefit is that we can change the chain ID at the start. This might not be that big of an advantage to include within a3p and you are right that the a3p can be used as based image for someone wanting this feature. Closing this PR.