Fixes KILTprotocol/ticket#2550.

**This PR will merge the changes into the `aa/dip` branch, which will be
the base branch for all the future DIP improvements until we reach a
version that we can merge into `develop` and deploy on some testnets in
the Peregrine runtime.**

## Base structure for DIP

This PR contains the following components:

* A pallet to send identity information to one or more destinations (DIP
sender)
* A pallet to receive such identity information from a source (DIP
receiver)
* A support crate that contains common (versioned) types, in future also
traits and auxiliary functions, if needed
* A template project consisting of 1. a template runtime for the
dip-sender, with its node counterpart, 2. a template runtime for the
dip-receiver, with its node counterpart, 3. an example XCM integration
test using [XCM emulator](https://github.com/shaunxw/xcm-simulator) (not
simulator) which connects the two template runtimes with a local Rococo
relay chain.

### Design

The current version assumes that anyone on the sender chain can dispatch
identity information on some target chain (with which there exists an
open HRMP channel). Ultimately, all the fees for dispatching the message
and process it on the receiver side will be paid by the extrinsic
submitter on the target chain. Right now, the submitter only pays for
the extrinsic dispatch on the source chain, and the chain itself uses
its own balance (liked to its sovereign account) on the target chain to
pay for the `Transact` execution. The `Transact` operation that
interacts with the `dip-receiver` pallet on the target chain has an
`OriginKind::Native`, so that there is no way for any user on the source
chain to dispatch such messages.

Right now, the basic structure and the templates use defaults for
everything, from proof generation to proof verification. One step at the
time, all these defaults will be replaced with the actual features.
Nevertheless, for two chains that have the same concept of `Identifier`
and `AccountId`, it is already possible to demo the complete e2e flow.
For the sake of our demonstration, the flow would go as follow,
**assuming that both the source and target chains are registered as
parachain on the same relaychain**:

1. The source chain requests to open an HRMP channel with the target
chain
2. The target chain accepts the request and the channel is open
3. The target chain issues some funds (enough to cover the demo use
case) to the sender chain's sovereign account
4. A user on the source chain creates a DID with a single authentication
key
5. The same user (but could be anyone else), calls the extrinsic on the
`dip-sender` pallet to send the merkle root of the DID to the target
chain, paying for the dispatch fee
6. The source chain sends the information to the target chain
7. The user calls the `dispatch_as` extrinsic of the `dip-receiver`
pallet which is deployed on the target chain, providing a merkle proof
of their DID document + details on the source chain. For now this check
always returns true.
8. Inside, the `dispatch_as` has a nested call which is dispatched with
the new `DipOrigin`, which pallets can now use if they expect extrinsics
to be DID-authorized.

## What's coming

I created tickets for each of the next steps, under the DIP milestone.
The tickets will take care of:

* Adding benchmarks and weights
* Introducing proper error handling
* Introducing proper DID signature verificaiton on the target template
chain (right now it's just a default behaviour)
* Introducing proper merkle proof generation (I tested that it works,
but removed those pieces from this PR for the ease of understanding)
* Introducing proper merkle proof verification (same as above)
* Adding an emergency brake in the sender pallet to stop dispatching
messages to a specific destination, e.g., if the sender sovereign
account on the destination chain does not have any more or if the
`Transact` encoding would fail
* Adding support for metadata beyond the simple DID details, e.g., proof
expiration time, etc.
* Replacing user-provided weights and assets with per-chain
configurations stored in the sender pallet
* More comments (I can work on this first if the code as it is it's too
hard to follow)
* Adding support for version negotiation. There is a basic concept of
versioning right now, but it can and should be expanded and improved.
* More unit and integration tests.

Probably more tickets will come out of this work, and will be tracked
separately in the same or in future milestones.

## How to test

A basic integration test of the two template runtimes is present in the
`dip-templates-xcm-tests` crate, inside the
`dip-template/runtimes/xcm-tests`. It can be run as usual with `cargo
test -p dip-templates-xcm-tests`.

Fixes KILTprotocol/ticket#2557 and fixes
KILTprotocol/ticket#2556.

This PR builds on top of the shell PR, and adds support for Merkle proof
for DID documents.

## Merkle proof structure

A DID merkle proof is, at the core, an order set of (key, value) pairs,
on which proof-of-inclusion and proof-of-non-inclusion can be performed.
This PR generates and validates merkle proofs where leaves are of two
types:

- a DID key reference leave, whose key is the tuple (key ID, key
relationship) and the value is an empty tuple
- a DID key details leave, whose key is the key ID and the value is the
key details

For each key reference leaf with a given key ID, the proof also has to
contain a key details leaf whose key is the key ID. Multiple reference
leaves can reference the same key details leaf, optimising the storage
size.

## New runtime APIs

There is a new runtime API which the DIP sender would expose, and that
allows anyone to generate a merkle proof for a given DID identifier and
set of key IDs. The result contains the merkle root (which must match
what other chains have stored in their `pallet-dip-receiver` map), and a
merkle proof, which includes blinded values and a set of key reference
and key details leaves for the keys identified by the provided key IDs.

## How to test

The setup flow is similar to that of
#489.
Specifically:

- Set up the local Rococo network onboarding the sender and receiver
chains with para IDs 2_000 and 2_001 respectively
- Open an HRMP channel from sender 2_000 to receiver 2_001
- Create a DID on the sender chain, e.g., using the
[kilt-did-utilities](https://github.com/KILTprotocol/kilt-did-utilities)
tool
![Screenshot 2023-03-27 at 10 00
48](https://user-images.githubusercontent.com/6704504/227900994-41f0f355-84bd-4b8a-a2a8-3a9c74447e59.png)
- Push the identity of the DID to the receiver chain via the
`pallet-dip-sender` extrinsic
![Screenshot 2023-03-27 at 10 01
13](https://user-images.githubusercontent.com/6704504/227901150-7e8c9c9d-8aac-4739-8ad3-fad4ba6ff5f8.png)
- Call the runtime API to generate a proof for the created DID with some
keys revealed
![Screenshot 2023-03-27 at 10 01
40](https://user-images.githubusercontent.com/6704504/227901309-94b4dbc9-ca83-4541-820d-d1bec6adc6f0.png)
- Use the generated proof to dispatch an extrinsic on the receiving
chain

### How to use the runtime API with polkadot apps

There is currently no support for the new runtime API in the public
polkadot apps instance. To use the runtime APIs from UI, please use [our
fork from the aa/dip-sender-template
branch](https://github.com/KILTprotocol/polkadot-apps/tree/aa/dip-sender-template),
by running `yarn && yarn build && yarn start`, then connecting to the
sender node WS socket.
For runtime augmentation within a Node script, please use our [SDK repo
from the aa/dip-merkle-proof
branch](https://github.com/KILTprotocol/sdk-js/tree/aa/dip-merkle-proof).

Fixes KILTprotocol/ticket#2587.

This PR adds a new trait `DipCallOriginFilter` that exposes a `fn
check_proof(call: Call, proof: Self::Proof) -> Result<Self::Success,
Self::Error>` function, called by the runtime to verify if a call can be
dispatched with the provided proof or not.

Fixes KILTprotocol/ticket#2588, based on top
of #502.

Won't be reviewed as it is merely a renaming PR. Will merge onto
`aa/dip` once #502 gets
reviewed and merged.

Fixes KILTprotocol/ticket#2553.

The main changes are:
* Removed half-baked versioning support, to re-introduce a proper one
once versioning and version negotiation will be tackeld
* Moved most of the logic from the `runtime-common` crate to a new
`kilt-dip-support` crate, after making all the types generic over all
the runtime configurations
* Updated the `pallet-dip-consumer` pallet to have a bunch more details,
more info below
* Updated the XCM-simulator based tests

## Updates to the `dip-support` crate

The `dip-support` does not contain any versioned types anymore. Support
for versioning was half-baked and has been removed. Proper thought
around versioning and version negotiation will happen in the (short)
future.

## New `kilt-dip-support` crate

The new `kilt-dip-support` crate contains types and traits that are not
generic over ANY DIP deployment, but that can be used by every consumer
that relies on the KILT chain as their provider. Hence, types are
opinionated towards the way KILT implements the DIP protocol, but
generic over the runtime configuration.
The most relevant types are `MerkleProofAndDidSignatureVerifier`,
exported from the root, `DidMerkleProofVerifier`, exported from the
`merkle` module, and `DidSignatureAndCallVerifier`, exported from the
`did` module. When they are chained together, they allow a user to
submit a Merkle proof revealing parts of their DID Document, and to use
one of the revealed keys to sign a specifically-crafted payload which
provides authenticity guarantees of the DID subject.

The default verification logic for the DID signature is the following:
1. Verify that the block number specified in the signature is no older
than `SIGNATURE_VALIDITY` blocks, as specified by the runtime
2. Verify that the signature can be verified over the encoded tuple
formed by `(call, identity_details, submitter_address, block_number,
genesis_hash, signed_extra)`, where `signed_extra` can be anything more
that the runtime might require be included in the signature.
3. Verify that one of the keys revealed in the Merkle proof can be used
to verify the provided signature
4. [OPTIONAL] If the type variant which also performs authorization
checks on the call itself is used, i.e., the
`DidSignatureAndCallVerifier` type, then the verification will also
include checking whether the used verification relationship can be used
to dispatch the specified call or not, as we do ourselves in our did
pallet within the `submit_did_call`, but in a more generic way.

The verification logic for Merkle proofs has remained unchanged, and it
can now be chained with the DID verification logic.

## Refreshed `pallet-dip-consumer`

The pallet has been updated so that now the `dispatch_as` extrinsic
takes a generic `Proof` instead of an `IdentityProof`, and internally
performs the following checks:

1. Verify the origin is a signed origin (as before)
2. Verify that the call passes a preliminary filter, before any heavy
computation is executed on the provided proof, via the
`DipCallOriginFilter` type. This step will typically immediately filter
out any calls that cannot be called with a Dip origin regardless of the
content of the proof.
3. Retrieves the identity details from storage, if they exist
4. Delegate everything to the `ProofVerifier`, which has a mutable
reference to the details fetched at step 3, in case they need to update
some values that will be written to storage (e.g., the nonce)
5. The maybe mutated details are written back into storage
6. The call is dispatched with the new `DipOrigin`, which carries the
additional information as returned by the `ProofVerifier`. In the demo
runtime, this will be the set of keys revealed as part of the Merkle
proof, that have been verified, parsed, and used for verifying the DID
signature provided as part of the proof.

The pallet logic is very simple, and most of the (complex) logic lies in
the types that have been exposed as part of the `kilt-dip-support`
crate. This makes the pallet easier to understand, and more generic to
be used in different contexts potentially for different identity
providers as well, where each provider might require users to provide a
different identity proof.

## Minor changes

Other things have been updated to reflect the relocation of some files
into the new `kilt-dip-support` crate.

## How to test

1. Build [this version](KILTprotocol/sdk-js#751)
of the SDK
2. Clone and `yarn install && yarn build` [this
version](https://github.com/KILTprotocol/polkadot-apps/pull/8) of the
PolkadotJS apps
3. Copy-paste the `@kiltprotocol/type-definitions` output into the root
`node_modules` folder of the PolkadotJS apps
4. Follow the steps to set up the HRMP channels, create the DIDs, and
push the identity commitment from provider to consumer
5. Use [this
version](KILTprotocol/kilt-did-utilities#14) of
the kilt-did-utilities CLI tool to generate a valid DIP DID signature.
6. Enjoy ☀️☀️☀️

Fixes KILTprotocol/ticket#2668.

Identity information should be entirely under the control of the DID
subject. Until now, it was not the case as anyone could have called the
`commit_identity` extrinsic for any DID subject.
This PR changes the origin check for the `commit_identity` extrinsic of
provider pallet from `EnsureSigned` to a configurable origin check.
The XCM integration tests have also been updated to use the
`EitherOfDiverse<EnsureRoot<AccountId>, EnsureDidOrigin<DidIdentifier,
AccountId>>;` implementation.
Now, except for cases where democracy decides to do this operation, the
DID subject has to agree to it by signing the operation, which will then
be dispatched via the `submit_did_call` extrinsic of the DID pallet.

The feature that any account can pay for the fees still applies, as that
is the same also for DID-signed extrinsics.

Fixes KILTprotocol/ticket#2566.

This PR changes the way XCM fees are handled for DIP. Before, the
provider parachain sovereign account on the consumer chain was paying
for the XCM fees, while now it is the sovereign account of the user that
triggered the operation on the provider chain, to also pay for the fees
on the receiver chain in whatever asset specified in the extrinsic. With
XCM v3, it's not possible for a parachain to charge an interior location
(e.g., with a `DescendOrigin` instruction), hence a new barrier and a
new origin converter have been introduced, which are supposed to be used
together to implement the feeing model DIP has envisioned.

## Relevant changes

### Reworked `XcmRouterIdentityDispatcher`

The `XcmRouterIdentityDispatcher` type used to be part of the
`pallet-dip-provider` pallet. Because it is really specific to KILT, it
has been moved into the `kilt-dip-support` crate.
Additionally, the router now packages the DIP XCM program with the
following instructions:
1. `ExpectOrigin` with the provider parachain origin, making sure the
same XCM message cannot be sent by regular users via the XCM pallet.
2. `DescendOrigin` with a new `AccountId32` representing the dispatcher
account ID on the provider chain.
3. `WithdrawAsset` with the `MultiAsset` specified in the
`commit_identity` extrinsic in the `pallet-dip-provider` pallet
4. `BuyExecution` with the max `Weight` specified in the
`commit_identity` extrinsic in the `pallet-dip-provider` pallet
5. `Transact` with `OriginKind::Native` and the same weight limit as
above
6. `RefundSurplus`
7. `DepositAsset` with any remaining assets in the holding registry back
to the dispatcher's account on the consumer chain

In the demo runtimes and tests, the `Account32Hash` location converter
has been used to convert the account ID information coming from the `X2`
junction containing the sibling provider parachain and the disptacher
account.

### Configurable origin for the `pallet_dip_provider::commit_identity`
extrinsic

The `CommitOrigin` origin was already configurable, but now its
`Success` result is required to implement the `SubmitterInfo` trait,
which returns the `AccountId` of the tx submitter, so that the
information can be used to compose the XCM message that will be sent to
destination (specifically it is included in the `DescendOrigin` and
`DepositAsset` instructions).
The trait has been implemented for the `AccountId32` type, which is
returned by the `EnsureSigned` origin check (which could be used for
tests), and for the `DidRawOrigin` type, which is returned by the
`EnsureDidOrigin` origin check (which has been used in the demo
runtimes).

### The `AllowParachainProviderAsSubaccount` barrier

For DIP to implement the feeing model devised here, where the user pays
for the fees on both chain, a new barrier + origin converter must be
integrated into the XCM configuration.
The `AllowParachainProviderAsSubaccount` barrier verifies that 1. the
origin of the XCM is a parachain with an ID that is returned by the
`ProviderParaId` generic type, and 2. the order of the instructions in
the XCM program matches exactly what is expected in the DIP flow. If
either the origin or the set of instructions is different, the barrier
will return an error.
To extend existing barrier, there are two additional types:
`OkOrElseCheckForParachainProvider` which tries to match the incoming
XCM message against the new `AllowParachainProviderAsSubaccount` barrier
if none of the previous barriers have succeeded (explicit approval), and
`ErrOrElseCheckForParachainProvider` which tries to match the XCM
message against the new barrier only if none of the previous barriers
have failed (explicit rejection).

### The `AccountIdJunctionAsParachain` origin converter

Since there is no way to convert an `X2` junction of parachain +
sub-account, the `AccountIdJunctionAsParachain` does just that. It takes
the `X2` junction of a *sibling* parachain + sub-account, if the
parachain matches the ID given by the `ProviderParaId` type, and
converts it into a `ParachainOrigin`.

**The origin converter and the barrier are meant to be used together,
otherwise configuring only one or the other opens the way to security
issues on the consumer chain!**

Fixes KILTprotocol/ticket#2730.

This PR introduces a new way of doing cross-chain identity bridging for
the same consensus system: state proofs. Few points make this solution
better than the previous XCM-based approach:

1. No need to anchor the commitment to each destination via XCM. The
commitment happens once on the provider chain and can be used everywhere
else.
2. No need to establish HRMP channels between the provider and the
relying party chain.
3. No outdated information. State proofs guarantee that always the
latest value of the commitment is used by the relying party. Of course
the identity info can still change without the commitment be updated,
but this is easily solvable by batching the commitment update together
with the operations where the identity bits change.

Few TODOs are present, and they will be addressed in next PRs.

## Main changes

* The overarching `MerkleProofAndDidSignatureVerifier` has been renamed
to `DipSiblingProviderStateProofVerifier`, with a bunch of additional
generics to make it agnostic over who the provider is, and also who the
relaychain is (e.g., Polkadot, Kusama, Rococo).
* The `process_identity_action` has been completely removed from the
`pallet-dip-consumer` pallet, since XCM is not required anymore
* Identity commitments are now stored on the **provider** chain rather
than the relying party chain.
* The `commit_identity` extrinsic also only has the identifier now,
without the need to specify `destination`, `asset` and `weight` since an
identity commitment is now usable everywhere by design.
* A new pallet `pallet-relay-store` which is meant to be used in
conjunction with the `pallet-dip-consumer` and that stores the last N
relay chain state roots, against which state proofs can be verified.
Relay chain state roots are stored in the `on_finalize`, before they are
cleaned by the `on_finalize` of the `cumulus-pallet-parachain-system`.

### Additions from the relaychain PR
(#553)

* A new `ChildParachainDipStateProof` and
`DipChildProviderStateProofVerifier` to be deployed on the relaychain to
start accepting DIP operations
* `SiblingParachainHeadProofVerifier` renamed to
`ParachainHeadProofVerifier`
* `KiltDipCommitmentsForDipProviderPallet` does not exist anymore, and
it's been replaced by `ProviderParachainStateInfoViaProviderPallet`,
which depends on the provider `Runtime` enum
* A new `HistoricalBlockRegistry` trait to be implemented by the
relaychain to provide historic block hashes against which DIP proofs can
be verified
* The `postit` pallet has been ported over from the Decoded demo branch,
and used instead of the lookup pallet to showcase DIP capabilities

## How to switch

- Remove all the XCM-related pallets from both provider and consumer
runtime templates
- Add the `pallet-relay-store` pallet to the consumer runtime template,
and configure all traits as needed

Fixes KILTprotocol/ticket#2552, by both
removing all occurrences of `.expect()` and `.unwrap()` and replacing
them with `Internal` errors, and by introducing error enums. The logic
is that for both the provider and the consumer, a generic error is
bubbled up from the runtime, and because of the constraints imposed by
Substrate, the error reason is encoded as a `u16`, where each "class" of
error is namespaced with a 255 value increment. A snippet of this is
shown below:

```rust
fn from(
    value: DipSiblingProviderStateProofVerifierError<
        ParachainHeadMerkleProofVerificationError,
        IdentityCommitmentMerkleProofVerificationError,
        DipProofVerificationError,
        DidSignatureVerificationError
    >,
) -> Self {
    match value {
        DipSiblingProviderStateProofVerifierError::ParachainHeadMerkleProofVerificationError(error) => {
            error.into()
        }
        DipSiblingProviderStateProofVerifierError::IdentityCommitmentMerkleProofVerificationError(error) => {
            u8::MAX as u16 + error.into() as u16
        }
        DipSiblingProviderStateProofVerifierError::DipProofVerificationError(error) => {
            u8::MAX as u16 * 2 + error.into() as u16
        }
        DipSiblingProviderStateProofVerifierError::DidSignatureVerificationError(error) => {
            u8::MAX as u16 * 3 + error.into() as u16
        }
    }
}
```

The specific reason for the error can then be retrieved and decoded
directly from the Polkadot Apps interface, as the example below shows,
where the first byte `01` indicates the enum variant index, the second
byte is the varint encoding of the SCALE-encoded u16, and the third and
forth bytes `e000` represent the `u16` error reason. This can be decoded
as decimal, where each value has a one-to-one link to a specific error
from the runtime.

<img width="554"
src="https://github.com/KILTprotocol/kilt-node/assets/6704504/f0985e17-7f3e-49f5-818c-6a7bc1ae1530">

The pallet consumer expects any other implementation of the DIP consumer
protocol to expose the proof verification error reason as a `u16`, but
of course developers are free to not give any meaning to it and treat
everything as a generic `InvalidProof` error.

Fixes KILTprotocol/ticket#2971 on top of
#572.

This PR adds support for versioning, by introducing support for the
following:

1. [PROVIDER PALLET] Generate an identity commitment for a specific
version
2. [PROVIDER PALLET] Delete a previously-created identity commitment of
a specific version
3. [PROVIDER RUNTIME API] Generate a DIP proof for a specific version
4. [CONSUMER] Add `Versioned*` types for DIP verifiers and DIP proofs
running on both a sibling parachain or the parent relaychain

Fixes KILTprotocol/ticket#2983.

Add a generic pallet to store deposits, as well as a hooking mechanism
to both the existing provider pallet (to allow runtimes that take
deposits to take deposits, or to do any other operation), and to the new
deposit pallet, which allows other pallets to clean up storage if a
storage is reclaimed back by its owner (e.g., an identity commitment is
removed).

Tests will follow in a separate PR, when time allows for them 😁 The
whole DIP branch won't be merged on `develop` before tests are written,
so it's not a risk. The logic has been tested by spinning up a local
network and trying to commit an identity (which takes a deposit), remove
the commitment (which frees up the deposit), re-commit the identity,
reclaim the deposit (which removes the commitment).

- [x] Implement logic for deposit removal hooks
- [x] Test
- [x] Review

Fixes KILTprotocol/ticket#2974 and based on
top of #574.

This is my take at trying to improve the DX of integrating DIP
components. The following is a list of the main changes introduced by
this PR:

- Definitions of traits that are only ever used and useful inside a
pallet have been changed to take a generic `Runtime` type that must
implement the pallet config, reducing the clutter when implementing them
- Additional bounds have been added to the associated types of those
traits, so that they don't need to be specified in the pallet config so
that we can have trait bounds of those types. So basically what used to
be the trait bounds on the pallet config, is not a trait bound on the
trait return type. I think this is also the "Rusty" way to go.
- The generic consumer types exported in `kilt-dip-support` crate have
been renamed with the `Generic` prefix, because I introduced two new
types, starting with `Kilt`, that make it easier to integrate any KILT
runtime as an identity provider, with the downside of having to depend
on the whole runtime definition, but there's also ways around that
(e.g., by having an intermediate crate that only implements the required
`Config` traits). Example 1 below shows the change.
- Better re-exports (feedback is welcome on this one). For instance, for
types that implement a basic version of a pallet's trait definition, the
type is exported directly from the pallet crate root, while the trait is
still namespaced behind the `mod traits`. Example 2 below.
- Change of the origin check for the `pallet_dip_consumer::dispatch_as`
extrinsic from `ensure_signed` to a generic
`T::DispatchOriginCheck::ensure_origin`, as long as the
`DispatchOriginCheck` returns an `AccountId` upon successful
verification.

## Example 1: old vs new way of integrating a consumer into a runtime
where KILT is a provider

### Old

```rust
pub type ProofVerifier = VersionedDipSiblingProviderStateProofVerifier<
	RelayStateRootsViaRelayStorePallet<Runtime>,
	ConstU32<2_000>,
	ProviderParachainStateInfoViaProviderPallet<ProviderRuntime>,
	AccountId,
	BlakeTwo256,
	KeyIdOf<ProviderRuntime>,
	ProviderAccountId,
	Web3Name,
	LinkableAccountId,
	10,
	10,
	u128,
	// Signatures are valid for 50 blocks
	FrameSystemDidSignatureContext<Runtime, 50>,
	DipCallFilter,
>;
```

### New (100% equivalent to the old one)

```rust
pub type ProofVerifier = KiltVersionedSiblingProviderVerifier<
	ProviderRuntime,    // KILT runtime definition
	ConstU32<2_000>,
	RelayStateRootsViaRelayStorePallet<Runtime>,    // Local runtime definition
	BlakeTwo256,
	DipCallFilter,
	10,
	10,
	50,
>;
```

## Example 2: example of type implementing a pallet's trait with a basic
implementation

For the trait

```rust
	pub trait IdentityCommitmentGenerator<Runtime>
	where
		Runtime: Config,
		Runtime::IdentityProvider: IdentityProvider<Runtime>,
	{
		type Error: Into<u16>;
		type Output: Clone + Eq + Debug + TypeInfo + FullCodec + MaxEncodedLen;

		fn generate_commitment(
			identifier: &Runtime::Identifier,
			identity: &IdentityOf<Runtime>,
			version: IdentityCommitmentVersion,
		) -> Result<Self::Output, Self::Error>;
	}
```

a basic implementation (mostly useful for tests) is provided

```rust
	pub struct DefaultIdentityCommitmentGenerator<Output>(PhantomData<Output>);

	impl<Runtime, Output> IdentityCommitmentGenerator<Runtime> for DefaultIdentityCommitmentGenerator<Output>
	where
		Runtime: Config,
		Output: Default + Clone + Eq + Debug + TypeInfo + FullCodec + MaxEncodedLen,
	{
		type Error = u16;
		type Output = Output;

		fn generate_commitment(
			_identifier: &Runtime::Identifier,
			_identity: &IdentityOf<Runtime>,
			_version: IdentityCommitmentVersion,
		) -> Result<Self::Output, Self::Error> {
			Ok(Output::default())
		}
	}
```

The pallet's crate will then export the trait with `pub mod traits`,
while the type is re-exported directly _also_ from the root with `pub
use traits::DefaultIdentityCommitmentGenerator`.

Ensuring the origin is a DID origin for the implementor of the provider
pallet might not be enough. They need to check that the origin indeed
matches the identifier being acted upon. Replacing `EnsureOrigin` with
`EnsureOriginWithArg` gives access to that information.

Tests will ALL be implemented in a different PR 😄

## fixes
[KILTprotocol/ticket#2551](KILTprotocol/ticket#2551)

This pull request introduces benchmark logic for the DIP templates. To
calculate default weights, a dummy implementation of the pallets in the
Peregrine runtime is defined. After the PR is approved, I will remove
the dummy implementation.


## Leftover tasks

- [x] Make the provider and consumer binaries compiles for benchmarking.
Currently the `VersionedSiblingParachainDipStateProof` type does not
implement the `WorstCase` trait, which is a blocker to use it in
benchmarks
- [x] Adjust the `DipProofVerifier` logic to allow any calls to be
dispatched when being benchmarked
- [x] Make sure everything compiles
- [x] Make sure benchmarks can actually be run for both provider and
consumer runtimes

---------

Co-authored-by: Antonio Antonino <[email protected]>

Fixes KILTprotocol/ticket#2560.

- [x] ~WIP.~ To rebase on top of
#583 once merged.

---------

Co-authored-by: Chris Chinchilla <[email protected]>

## fixes https://github.com/KILTprotocol/ticket/issues/3023

### changed

* moved the `deposit_event(Event::AttestationRemoved)` to the
`remove_attestation` so that the event shall never be forgotten to be
deposited.
* restructured Attestation event
  * added authorized_by to revoked and removed, added ctype
* test attestation events
* removed unused `DepositReclaimed` events
* deposit `W3nReleased` event when governance bans an already used w3n

## Metadata Diff to Develop Branch

<details>
<summary>Peregrine Diff</summary>

```
!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
[≠] pallet 62: Attestation -> 4 change(s)
  - events changes:
    [≠]  0: AttestationCreated ( : AttesterOf<T>, : ClaimHashOf<T>, : CtypeHashOf<T>, : Option<AuthorizationIdOf<T>>, )  )
        [Signature(SignatureChange { args: [Changed(0, [Name(StringChange("", "attester"))]), Changed(1, [Name(StringChange("", "claim_hash"))]), Changed(2, [Name(StringChange("", "ctype_hash"))]), Changed(3, [Name(StringChange("", "authorization"))])] })]
    [≠]  1: AttestationRevoked ( : AttesterOf<T>, : ClaimHashOf<T>, )  )
        [Signature(SignatureChange { args: [Changed(0, [Name(StringChange("", "authorized_by")), Ty(StringChange("AttesterOf<T>", "AuthorizedByOf<T>"))]), Changed(1, [Name(StringChange("", "attester")), Ty(StringChange("ClaimHashOf<T>", "AttesterOf<T>"))]), Added(2, ArgDesc { name: "claim_hash", ty: "ClaimHashOf<T>" })] })]
    [≠]  2: AttestationRemoved ( : AttesterOf<T>, : ClaimHashOf<T>, )  )
        [Signature(SignatureChange { args: [Changed(0, [Name(StringChange("", "authorized_by")), Ty(StringChange("AttesterOf<T>", "AuthorizedByOf<T>"))]), Changed(1, [Name(StringChange("", "attester")), Ty(StringChange("ClaimHashOf<T>", "AttesterOf<T>"))]), Added(2, ArgDesc { name: "claim_hash", ty: "ClaimHashOf<T>" })] })]
    [-] "DepositReclaimed"

[≠] pallet 63: Delegation -> 1 change(s)
  - events changes:
    [-] "DepositReclaimed"

SUMMARY:
- Compatible.......................: true
- Require transaction_version bump.: false

!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
```

</details>

<details>
<summary>Spiritnet Diff</summary>

```
!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
[≠] pallet 62: Attestation -> 4 change(s)
  - events changes:
    [≠]  0: AttestationCreated ( : AttesterOf<T>, : ClaimHashOf<T>, : CtypeHashOf<T>, : Option<AuthorizationIdOf<T>>, )  )
        [Signature(SignatureChange { args: [Changed(0, [Name(StringChange("", "attester"))]), Changed(1, [Name(StringChange("", "claim_hash"))]), Changed(2, [Name(StringChange("", "ctype_hash"))]), Changed(3, [Name(StringChange("", "authorization"))])] })]
    [≠]  1: AttestationRevoked ( : AttesterOf<T>, : ClaimHashOf<T>, )  )
        [Signature(SignatureChange { args: [Changed(0, [Name(StringChange("", "authorized_by")), Ty(StringChange("AttesterOf<T>", "AuthorizedByOf<T>"))]), Changed(1, [Name(StringChange("", "attester")), Ty(StringChange("ClaimHashOf<T>", "AttesterOf<T>"))]), Added(2, ArgDesc { name: "claim_hash", ty: "ClaimHashOf<T>" })] })]
    [≠]  2: AttestationRemoved ( : AttesterOf<T>, : ClaimHashOf<T>, )  )
        [Signature(SignatureChange { args: [Changed(0, [Name(StringChange("", "authorized_by")), Ty(StringChange("AttesterOf<T>", "AuthorizedByOf<T>"))]), Changed(1, [Name(StringChange("", "attester")), Ty(StringChange("ClaimHashOf<T>", "AttesterOf<T>"))]), Added(2, ArgDesc { name: "claim_hash", ty: "ClaimHashOf<T>" })] })]
    [-] "DepositReclaimed"

[≠] pallet 63: Delegation -> 1 change(s)
  - events changes:
    [-] "DepositReclaimed"

SUMMARY:
- Compatible.......................: true
- Require transaction_version bump.: false

!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
```

</details>

## Checklist:

- [x] I have verified that the code works
- [ ] No panics! (checked arithmetic ops, no indexing `array[3]` use
`get(3)`, ...)
- [x] I have verified that the code is easy to understand
  - [ ] If not, I have left a well-balanced amount of inline comments
- [x] I have [left the code in a better
state](https://deviq.com/principles/boy-scout-rule)
- [x] I have documented the changes (where applicable)
* Either PR or Ticket to update [the
Docs](https://github.com/KILTprotocol/docs)
    * Link the PR/Ticket here

Unrelated changes from the DIP PR.

* fix formatting
* sort alphabetically
* implement Ord, Eq, Default for AsciiW3n

## Metadata Diff to Develop Branch

<details>
<summary>Peregrine Diff</summary>

```
!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
No change detected
SUMMARY:
- Compatible.......................: true
- Require transaction_version bump.: false

!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
```

</details>

<details>
<summary>Spiritnet Diff</summary>

```
!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
No change detected
SUMMARY:
- Compatible.......................: true
- Require transaction_version bump.: false

!!! THE SUBWASM REDUCED DIFFER IS EXPERIMENTAL, DOUBLE CHECK THE RESULTS !!!
```

</details>

## Checklist:

- [x] I have verified that the code works
- [ ] No panics! (checked arithmetic ops, no indexing `array[3]` use
`get(3)`, ...)
- [x] I have verified that the code is easy to understand
  - [ ] If not, I have left a well-balanced amount of inline comments
- [x] I have [left the code in a better
state](https://deviq.com/principles/boy-scout-rule)
- [x] I have documented the changes (where applicable)
* Either PR or Ticket to update [the
Docs](https://github.com/KILTprotocol/docs)
    * Link the PR/Ticket here

Co-authored-by: Antonio Antonino <[email protected]>

Addresses most of the outstanding comments in
#494. Which ones have been
addressed are specified in that PR.

Based on top of #494.

Mirrors the behaviour in the provider template, with the following
differences:

1. The deposit is calculated taking into account the actual length of an
identity commitment.
2. The key that is stored in the pallet deposit storage is an enum,
which allows more keys to be added in the future

Partially fixes KILTprotocol/ticket#3051.
Needed for easier DIP-SDK integration tests. Binaries will have to be
compiled and exported in a different PR.