Keep last parameters when updating Glue in Delta

[ebyhr]

Description

Otherwise, DeltaLakeTableMetadataScheduler fails internally.
I manually tested and didn't add a test because this issue is specific to V1 (legacy).

Release notes

(x) This is not user-visible or is docs only, and no release notes are required.

[raunaqmorarka]

Could you add some more detail about the failure scenario like the error stacktrace or steps to get to the error ?

[ebyhr]

@raunaqmorarka This is the sample stacktrace when executed COMMENT ON TABLE delta.ebyhr.test_scheduler IS 'test comment'. This issue always happened in all write operations.

java.lang.IllegalArgumentException: Multiple entries with same key: trino_last_transaction_version=6 and trino_last_transaction_version=5
	at com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:382)
	at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:376)
	at com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:249)
	at com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:136)
	at com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:98)
	at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:579)
	at com.google.common.collect.ImmutableMap$Builder.buildOrThrow(ImmutableMap.java:607)
	at io.trino.plugin.deltalake.metastore.glue.v1.DeltaLakeGlueV1MetastoreTableOperations.commitToExistingTable(DeltaLakeGlueV1MetastoreTableOperations.java:66)
	at io.trino.plugin.deltalake.metastore.DeltaLakeTableMetadataScheduler.updateTable(DeltaLakeTableMetadataScheduler.java:174)
	at io.trino.plugin.deltalake.metastore.DeltaLakeTableMetadataScheduler.lambda$process$1(DeltaLakeTableMetadataScheduler.java:152)
	at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:317)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1570)

[raunaqmorarka]

May be we can handle it by filtering out old TRINO_LAST_TRANSACTION_VERSION from a previous step instead ?
Using buildKeepingLast relies on keys being inserted in certain order which somebody might change without knowing we relied on it to keep only latest TRINO_LAST_TRANSACTION_VERSION

[ebyhr]

Let me handle in a follow-up because buildKeepingLast() is consistent with other metatore logic at this time.