Implement detailed logging for XCM failures

[raymondkfcheung]

This PR enhances diagnostics across XCM-related components by implementing more detailed logging, especially for failures. The primary aim is to improve visibility into XCM errors (e.g., within map_err blocks), enabling faster troubleshooting for developers and node operators.

Key enhancements include:

• Logging specific error conditions (e.g., BadVersion, BadLocation, execution errors).
• Including essential context in error logs (e.g., message hashes, origin, destination, relevant parameters).
• Standardising log targets for easier analysis (e.g., xcm::module::function_name).
• Clarifying log messages.

This work continues #7003 and partially addresses #6119.

Integration

Downstream projects using XCM functionalities should see improved diagnostic logs without needing direct integration changes, as this primarily enhances internal logging. Node operators will find new, more detailed XCM error logs, aiding in monitoring and troubleshooting. Log parsing scripts might need updates for new log formats.

Review Notes

This PR enhances logging throughout XCM-related code paths, particularly in error handling (e.g., map_err blocks), to improve failure visibility.

Reviewers are encouraged to assess:

• Clarity & Actionability: Are logs clear, concise, and actionable for failures?
• Context: Do error logs capture essential context (message hash, origin, destination, error specifics, parameters) appropriately for their level?
• Log Levels: Is the chosen log level (e.g., error, warn, debug, trace) suitable? Are any level adjustments appropriate?
• Targets: Are target: fields (e.g., xcm::module::function) consistent and specific?
• Error Accuracy: Do logs accurately reflect the handled error condition?
• Impact: Logging should minimally affect core logic and performance; favour simple logging of existing/easily derived data.

[raymondkfcheung]

/cmd prdoc --audience runtime_dev --bump patch

[acatangiu]

Please change all the log::error! to log::debug! - error logs are reserved for errors relevant to node operator - these types of runtime errors should be coming up only when debugging (otherwise validators get spammed with error logs for on-chain stuff that has no relevance to them).

The rest is good!

[bkontur]

definitely not error here, because we use XcmpQueue in XcmRouter tuple and for example on AssetHubs, we have other routers after XcmpQueue for Ethereum or Polkadot/Kusama bridge routers.
So basically, we would log this error for every other location than (1, [Parachain(id)]) => {

Suggested change

	log::error!(target: LOG_TARGET, "Failed to validate XCM destination: unexpected location {d:?}");
	log::trace!(target: LOG_TARGET, "Failed to validate XCM destination: unexpected location {d:?}");

[raymondkfcheung]

Shall I use debug or trace on xcmp-queue/src/lib.rs?

[bkontur]

this tuple SendXcm routing is expected not to pass depending on the d, so definitely trace,
maybe questionable if really need a log here, but if so, then trace

[raymondkfcheung]

Agreed, removed logs.