[Authorize upgrade] Upgrade authorization by Polkadot relay chain

[karolk91]

This pull request introduces scenarios of Runtime upgrades authorization by Relay Chain.

Scenarios to cover:

• Polkadot relay chain authorizes upgrade for itself
• Polkadot relay chain authorizes upgrade for Polkadot Asset Hub
• Polkadot relay chain authorizes upgrade for Polkadot Bridge Hub
• Polkadot relay chain authorizes upgrade for Polkadot Coretime
• Polkadot relay chain authorizes upgrade for Polkadot People
• Polkadot relay chain authorizes upgrade for Polkadot Collectives

This pull request covers Polkadot Network, other PRs will be created for Kusama network and AssetHub Next based scenarios

[karolk91]

hey @xlc , @rockbmb

I would like to discuss with you the approach I used here, that I'm not sure if it looks nice.

You will notice that I've introduced test file that involve scenarios for 3 chains, and following current pattern of naming files I'm using:
chain1.chain2.chain3.test.ts

the truth is that chain3 is always Collectives, so more like
chain1.chain2.collectives.test.ts

I was wondering if that looks ok to you, or should I ignore Collectives part (as something that is fixed among tests, but will probably be skipped for notifications purposes) ?

Also, I have in mind a test that will involve all the system chains and relay chain, so something like an edge case scenario where relay chain approves upgrade for all system chains at once - how to fit that scenario? should that be part of polkadot.test.ts or maybe polkadot.allSystem.test.ts, how do you see it?

[xlc]

you can do .map(x => { x.message.id = '(redacted)'; return x }
or I can add a redactKeyPaths: string[][] and basically _.set(x, keyPath, '(redacted)') to the object

[karolk91]

thank you for looking into this, seems I must have confused/overlooked something in this case as I couldn't justify this again on second look - id is properly redacted here, no conflicts with other nested id attributes

I have removed this misleading comment - nothing to be done here

[xlc]

chain1.chain2.chain3.test.ts is fine. we can easily update the notification to support such case.
for the one with all the system chains, I will say just make it polkadot.test.ts

[karolk91]

chain1.chain2.chain3.test.ts is fine. we can easily update the notification to support such case. for the one with all the system chains, I will say just make it polkadot.test.ts

I have created the issue to track this here #228 separately from this PR