SYS-4220 Disable lowering

[nahuseyoum]

Proposed changes

This PR introduces a flag to toggle lowering capabilities of the chain.

Type of change/Merge

🚨What type of change is this PR?

Put an x in the boxes that apply

• Release
  • Increase versions
  • Baseline tests passed
  • Release type:
    • Major release
    • Minor release
    • Patch release

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR.

• You describe the purpose of the PR, e.g.:
  • What does it do?
  • Highlight what important points reviewers should know about;
  • Indicates if there is something left for follow-up PRs.
• Documentation updated
• Business logic tested successfully
• Verify First, Write Last: In Substrate development, it is important that you always ensure preconditions are met and return errors at the beginning. After these checks have completed, then you may begin the function's computation.

Further comments

[thadouk]

I prefer having a set_config function where different values can be configured
we already have set_lower_schedule_period so it would be better if we have one set admin function.

[nahuseyoum]

I personally prefer having smaller extrinsics that do specific tasks. They are easier to test, benchmark and reason with. Happy to hear other thoughts

[micaelffrancoAV]

For me, with the little experience I have, I feel like smaller extrinsics are easier to understand but happy either way!

[thadouk]

I'm afraid I have to disagree, multiple entry points for sudo configuration is a security concern.
The codebase increases significantly if you have to replicate all origin and benchmark tests for each one of the entry points, making it difficult to navigate through files.
This is a common practice in many pallets with complex config.
Alternatively, we can make this a const, defined by the runtime. Its clean and minimal and the way many pallets are configured in substrate.

[thadouk]

One event for settings is better to avoid bloating the pallet codebase.

[nahuseyoum]

I personally prefer having specific events that describe exactly what is happening instead of a generic one with different argument. Again happy to hear what others think.

[thadouk]

The functionality of the code introduced on this PR is correct, the approach to changing the configuration should improve as mentioned.
Although this has an overhead, this can be done on a separate refactor since the functionality needs to be expedited.
Approved on that basis.