chore: improve DX

[ntn-x2]

Fixes https://github.com/KILTprotocol/ticket/issues/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

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)

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

	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

	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.

[Ad96el]

LGTM. I'm considering adding a fourth runtime, where the required configuration traits for pallets are implemented. This would make integration easier for chains that want to use KILT as the provider. What do you think? I can provide a more detailed review in a week when I have a deeper understanding of the DIP implementation. If necessary, a second review can follow. :)

[ntn-x2]

LGTM. I'm considering adding a fourth runtime, where the required configuration traits for pallets are implemented. This would make integration easier for chains that want to use KILT as the provider.

If you mean so that a consumer can call the Kilt-flavored struct to implement the ProofVerifier trait, then yes, that makes sense, I mentioned in the third point of the bullet list above. That would probably be exported inside the kilt-dip-support crate, in its own module and re-exported from the root. If you mean something else, then I don't think I understood your point.

[Ad96el]

I would likely review it once more, if I have the time, but I believe it's ready to be merged

[trusch]

This looks nice, especially the Kilt specific types will make it super easy for consumers to integrate with us without loosing the generic types that would work with any provider!