/// Error codes used in XCM. The first errors codes have explicit indices and are part of the XCM
/// format. Those trailing are merely part of the XCM implementation; there is no expectation that
/// An asset transaction (like withdraw or deposit) failed (typically due to type conversions).
/// An asset cannot be withdrawn, potentially due to lack of ownership, availability or rights.
/// Used by `ExpectAsset`, `ExpectError` and `ExpectOrigin` when the expectation was not true.
/// Execution of the XCM would potentially result in a greater weight used than weight limit.
/// generally it means that the conditions surrounding the message were not such that the chain
/// considers the message worth spending time executing. Since most chains lift the barrier to
/// execution on appropriate payment, presentation of an NFT voucher, or based on the message
/// These can be amalgamated in tuples to form sophisticated routing systems. In tuple format, each
/// router might return `NotApplicable` to pass the execution to the next sender item. Note that
/// each `NotApplicable` might alter the destination and the XCM message for to the next router.
/// fn validate(_: &mut Option<MultiLocation>, _: &mut Option<Xcm<()>>) -> SendResult<Infallible> {
/// fn validate(destination: &mut Option<MultiLocation>, message: &mut Option<Xcm<()>>) -> SendResult<()> {
/// fn validate(destination: &mut Option<MultiLocation>, message: &mut Option<Xcm<()>>) -> SendResult<()> {
/// If it is not a destination which can be reached with this type but possibly could by others,
/// Convenience function for using a `SendXcm` implementation. Just interprets the `dest` and wraps
/// Convenience function for using a `SendXcm` implementation. Just interprets the `dest` and wraps
/// Returns either `Ok` with the price of the delivery, or `Err` with the reason why the message
/// Generally you'll want to validate and get the price first to ensure that the sender can pay it