XCM remote lock consumers

[muharem]

The current version of the remote lock entry only tracks the total count of its local users, which means that each local user can only hold the entire amount of the lock. However, to allow for partial locking and unlocking of the remote lock, as well as the ability to extend the lock for a specific user, we need more information than just the user count. Specifically, we store identifiers for each user and the exact amount held by them.
Also in this PR we rename users to consumers.

cumulus companion: paritytech/cumulus#2463

Migration

Since there is no universal solution to migrate the storage to the new storage version, all clients who have used the remote locks has to write the migration them-self. Contact me for support.
All polkadot and cumulus repos' runtimes have no trusted lockers, hence the changed storage item is empty, no migration needed.
I also assume no one yet using the feature, since it was introduced in XCMv3, and there is no yet API to allocate the remote lock.

[muharem]

bot rebase

[paritytech-processbot]

Rebased

[bkchr]

All polkadot and cumulus repos' runtimes have no trusted lockers, we don't need a transaction for them for sure.
Probably no one yet using the feature, since it was introduced in XCMv3, and there is no yet API to allocate the remote lock. Regardless there is no universal solution to migrate to the new storage version.

Are you 100000% sure that no one is using this right now? Otherwise we should at least put the runtime migration label and leave some small text in the description on how to check and then at least tell them to reach out as I assume they may can not write the migration on their own.

[muharem]

All polkadot and cumulus repos' runtimes have no trusted lockers, we don't need a transaction for them for sure.
Probably no one yet using the feature, since it was introduced in XCMv3, and there is no yet API to allocate the remote lock. Regardless there is no universal solution to migrate to the new storage version.

Are you 100000% sure that no one is using this right now? Otherwise we should at least put the runtime migration label and leave some small text in the description on how to check and then at least tell them to reach out as I assume they may can not write the migration on their own.

I cant be that sure (:, but worth the label for sure.

[muharem]

bot rebase

[paritytech-processbot]

Rebased

[muharem]

bot merge

[xlc]

I am reading this code and super confused.
consumers is never pushed. RemoteLockConsumerIdentifier is never passed or created.

How do we exactly configure our chain for MaxRemoteLockConsumers and RemoteLockConsumerIdentifier??

[muharem]

@xlc right now its not utilized. the main purpose of this PR was to change the storage schema into desired one.
the xcm pallet will need to provide means to hold/release a lock on a remote lock with a given identifier.