XCM: Deny barrier checks for nested XCMs with specific instructions to be executed on the local chain

[bkontur]

Resolves (partially): #7148
Depends on: #7169

Description

For context and additional information, please refer to Problem 2 - Barrier vs nested XCM validation.

TODO

• Evaluate PoC:
  • Keep it as it is and be explicit:
    1. Name the Deny barriers for the top level.
    2. Name the Deny barrier for nested with DenyInstructionsWithXcmFor.
  • Alternatively, hard-code those three instructions in DenyThenTry, so we wouldn’t need DenyInstructionsWithXcm. However, this approach wouldn’t be as general.
  • Another possibility is to check DenyInstructionsWithXcm::Inner for the actual message, so we don’t need duplication for top-level and nested (not sure, maybe be explicit is good thing) - see Problem2 - example. Instead of this:

  DenyThenTry<
               (
                              // Deny for top level XCM program 
                              DenyReserveTransferToRelayChain,
                              // Dedicated barrier for nested XCM programs
                              DenyInstructionsWithXcmFor<
                                               // Repeat all Deny filters here 
                                               DenyReserveTransferToRelayChain,
                               >
               ),
  

  we could just use:

  DenyThenTry<
               (
                              // Dedicated barrier for XCM programs
                              DenyInstructionsWithXcmFor<
                                               // Add all `Deny` filters here 
                                               DenyReserveTransferToRelayChain,
                                               ...
                               >
               ),
  

• Consider better name DenyInstructionsWithXcmFor
• Clean-up and docs
• Set for the runtimes where we use DenyThenTry, but at first we need to merge xcm: fix for DenyThenTry Barrier #7169 or rebase this branch on the top of yrong:fix-for-deny-then-try
• Schedule sec.audit

[raymondkfcheung]

Regarding the naming, maybe we can use DenyNestedXcmInstructions, which may be better to state clearly with nested XCMs.

[raymondkfcheung]

/cmd fmt

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13029978826
Failed job name: fmt

[raymondkfcheung]

/cmd fmt

[raymondkfcheung]

DenyInstructionsWithXcm can't reject the top level Deny barrier. Other two approaches (#7351) can deny earlier.