fix: add storage item for feature control

[felixfaisal]

This PR updates the code to make use of storage item instead of feature-guard for skip-scheduled-enclave-check

• Generate Weights for new extrinsic
  So I initially thought that I would need to benchmark this new extrinsic, but I also see that not all extrinsics are benchmarked, and I'm using the same weights as one of the extrinsics, I think the operation of this extrinsic fairly simple as it performs a single write, So I also don't think we need to perform actually benchmarking as there is no worst case complexity.
• Unit test to test this PR
  So I've updated the unit tests to make use of the storage item instead of feature guards.

I'm actually not sure if this PR does all the necessary changes 😅

• So we can also do the same skip-ias-dev but I want to do it another PR and not in this
• We have to update deploy.sh however I'm not sure if we have to Alice as root in production environment or we should manually call this extrinsic

[linear]

P-356 Prefer runtime control over feature guard

[Kailai-Wang]

Thanks!

We have to update deploy.sh however I'm not sure if we have to Alice as root in production environment or we should manually call this extrinsic

In prod we have parachains already running, so we have to either rely on the default value of this storage, or set it manually (which is hard for automation)

[Kailai-Wang]

Looks good now! Only a small thing

[kziemianek]

What do you think about letting primary validateer (first worker to register in teerex's enclave registry) to set scheduled mrenclave to it's actual mrenclave in dev ?

Would we still need skip-scheduled-enclave-check feature/fag ?

[Kailai-Wang]

What do you think about letting primary validateer (first worker to register in teerex's enclave registry) to set scheduled mrenclave to it's actual mrenclave in dev ?

Would we still need skip-scheduled-enclave-check feature/fag ?

We could do that but it will still require scheduled-enclave-check for subsequent registration. So it saves the step to set the first / genesis mrenclave from external

[kziemianek]

What do you think about letting primary validateer (first worker to register in teerex's enclave registry) to set scheduled mrenclave to it's actual mrenclave in dev ?
Would we still need skip-scheduled-enclave-check feature/fag ?

We could do that but it will still require scheduled-enclave-check for subsequent registration. So it saves the step to set the first / genesis mrenclave from external

You mean if code changes ... hmm maybe we can override it everytime.

[felixfaisal]

So I made a few changes

• Instead of calling an extrinsic during local-setup, I've included this in the genesis spec for rococo-dev chain
• This was because I had a few CI problems, and I felt this was also better than calling an extrinsic during the launch.

[Kailai-Wang]

Looks good, thanks! Just one small thing

[Kailai-Wang]

Hmm there seems to be CI error