OP: refactor: consolidate IS_ENABLED into CONFIG

[maurolacy]

@bap2pecs cloned issue babylonchain/babylon-contract#194 on 2024-06-27:

when I was querying the contract to see its states I need to run both

$ QUERY='{"config":{}}'                                                             [13:41:57]

babylond query wasm contract-state smart $CONTRACT_ADDR "$QUERY" --chain-id euphrates-0.2.0 --node https://rpc-euphrates.devnet.babylonchain.io -o json

{"data":{"consumer_id":"op-stack-l2-12345","activated_height":1022293}}

and

$ QUERY='{"is_enabled":{}}'                                                         [13:42:05]

babylond query wasm contract-state smart $CONTRACT_ADDR "$QUERY" --chain-id euphrates-0.2.0 --node https://rpc-euphrates.devnet.babylonchain.io -o json

{"data":true}

then I realized that we should:

• merge the isenabeld state into config

  • update ExecuteMsg::SetEnabled accordingly

• remove QueryMsg::IsEnabled

this will be cleaner

[maurolacy]

@bap2pecs commented on 2024-06-28:

discussed w @parketh offline.

i think the current setup is good in that there is seperation between immutable values (config) and mutable values (is_enabled)

the immutable values would normally be called sth like ‘ChainInfo’ and then the configs can be ‘ChainConfig’

let's keep it for now

[maurolacy]

@bap2pecs commented on 2024-07-08:

thinking about it more. i think having two state vars is probably unnecessary. for example, in itest/opstackl2/devnet-data/devnetL1.json, there are some fields immutable but some seems mutable but they don't use two separate files.

i also remember for CDK deployment parameters, some are immutable but some change be changed in the CDK contract later