Add catalogVersion into QueryInputMetadata & QueryOutputMetadata

[findinpath]

Description

As a follow-up on @dain 's work for adding version to the CatalogHandle, this PR adds catalogVersion to the inputs and output fields from QueryIOMetadata to eventually distinguish the catalog version from the output sent to the event listener for the tables involved in Trino queries.

Additional context and related issues

Release notes

(x) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text:

[findinpath]

CI failure #17500 #16277

[erichwang]

In general this looks good, but would it be possible to use CatalogVersion instead of String in the Input/Output analysis parts. It's fine to keep it as String in the eventlistener parts.

[erichwang]

Is there anyway we can use the Object form of CatalogVersion here instead of string?

[findinpath]

I changed the type of the field to Object instead of String / CatalogHandle.CatalogVersion.
The only constraint is now on the constructor to have CatalogHandle.CatalogVersion as a parameter so that it knows during the deserialization that the value

"catalogVersion": "default"

is to be converted back to a CatalogHandle.CatalogVersion instead of String like it would normally happen without this extra information.

[findinpath]

We could add a test on io.trino.execution.TestEventListenerBasic#testPrepareAndExecute for retrieving the catalogVersion from the inputs. However, the catalog version for this test is computed by the FileCatalogStore based on a hashing algorithm that may eventually cause changes in the test throughout the time.

trino/core/trino-main/src/main/java/io/trino/connector/FileCatalogStore.java

Lines 170 to 186 in ebed7dc

	/**
	* This is not a generic, universal, or stable version computation, and can and will change from version to version without warning.
	* For places that need a long term stable version, do not use this code.
	*/
	static CatalogVersion computeCatalogVersion(String catalogName, ConnectorName connectorName, Map<String, String> properties)
	{
	Hasher hasher = Hashing.sha256().newHasher();
	hasher.putUnencodedChars("catalog-hash");
	hashLengthPrefixedString(hasher, catalogName);
	hashLengthPrefixedString(hasher, connectorName.toString());
	hasher.putInt(properties.size());
	ImmutableSortedMap.copyOf(properties).forEach((key, value) -> {
	hashLengthPrefixedString(hasher, key);
	hashLengthPrefixedString(hasher, value);
	});
	return new CatalogVersion(hasher.hash().toString());
	}

The current hashed value of the input is a54a4dabd3c2c54b5c98ab9451385fae3f0487a110f722aa3d387e502f139234

[erichwang]

@findinpath, sorry I think I probably wasn't clear enough last time. What I meant was whether we could use the proper CatalogVersion as the type everywhere if possible. If not for some reason, String is an ok alternative for event logging, but it's always better to use the full type if possible.

[erichwang]

Assuming the tests pass, this looks good to me.

@electrum can you get this merged when ready?

[erichwang]

@electrum ping