Remove PolarisDiagnostics from json utils

[XN137]

handling of JsonProcessingException is quite inconsistent across the code base.
many places report the exceptions to PolarisDiagnostics but a lot of counter-examples exist as well.

if we remove the dependency on PolarisDiagnostics this enables a lot of transitive cleanups. most prominently TaskEntity no longer needs to call CallContext.getCurrentContext and thus we can avoid using CallContext.setCurrentContext in many outside callers.

overall this works towards the removal of the ThreadLocal<CallContext> CURRENT_CONTEXT and towards proper CDI.

[XN137]

list of some examples where JSON error handling is inconsistent / not using PolarisDiagnostics:

• polaris/polaris-core/src/main/java/org/apache/polaris/core/entity/PolarisBaseEntity.java

  Lines 112 to 117 in 9ff2ca1

  	try {
  	return MAPPER.readValue(properties, new TypeReference<>() {});
  	} catch (JsonProcessingException ex) {
  	throw new IllegalStateException(
  	String.format("Failed to deserialize json. properties %s", properties), ex);
  	}

• polaris/polaris-core/src/main/java/org/apache/polaris/core/persistence/PolarisObjectMapperUtil.java

  Lines 181 to 188 in 25509f2

  	} catch (IOException e) {
  	LOGGER
  	.atWarn()
  	.addKeyValue("json", entity.getProperties())
  	.addKeyValue("error", e.getMessage())
  	.log("Unable to parse task properties");
  	return null;
  	}

• polaris/polaris-core/src/main/java/org/apache/polaris/core/policy/PolarisPolicyMappingRecord.java

  Lines 116 to 122 in 21d1c23

  	try {
  	this.parameters =
  	parameters == null ? EMPTY_MAP_STRING : MAPPER.writeValueAsString(parameters);
  	} catch (JsonProcessingException ex) {
  	throw new IllegalStateException(
  	String.format("Failed to serialize json. properties %s", parameters), ex);
  	}

• polaris/polaris-core/src/main/java/org/apache/polaris/core/storage/PolarisStorageConfigurationInfo.java

  Lines 113 to 117 in de351de

  	try {
  	return DEFAULT_MAPPER.writeValueAsString(this);
  	} catch (JsonProcessingException e) {
  	throw new RuntimeException(e);
  	}

• polaris/service/common/src/main/java/org/apache/polaris/service/config/FeaturesConfiguration.java

  Lines 60 to 63 in 4c7ae00

  	} catch (JsonProcessingException e) {
  	throw new RuntimeException(
  	"Invalid JSON value for feature configuration: " + configName, e);
  	}

• polaris/polaris-core/src/main/java/org/apache/polaris/core/entity/CatalogEntity.java

  Line 220 in 987c554

  return ConnectionConfigInfoDpo.deserialize(new PolarisDefaultDiagServiceImpl(), configStr);

[XN137]

rebased after ca85339 due to tiny conflict in ManagementServiceTest.java

[dimas-b]

LGTM 👍 Nice refactoring to reduce reliance on thread locals! Thanks, @XN137 !

[dimas-b]

nit: Add ex's message to the re-thrown exception message for each of trouble-shooting?

[XN137]

i've added the message as you suggested.

iirc some lint tools flag this as a problem, as you are simply repeating the same information.
also from my experience the jackson exceptions are often not very helpful if you dont also have the exact JSON input to compare to (which i did not include because i think properties could contain credentials etc.).

[dimas-b]

not "simply" repeating :) In some cases only the exception message is available for debugging, while the full stack trace takes extra efforts to obtain.

I'm fine either way, but thanks for addressing my nitpick :)

[XN137]

rebased after trivial merge conflicts in:

persistence/relational-jdbc/src/main/java/org/apache/polaris/persistence/relational/jdbc/JdbcMetaStoreManagerFactory.java
polaris-core/src/main/java/org/apache/polaris/core/persistence/LocalPolarisMetaStoreManagerFactory.java

[snazy]

@XN137 can you fix the conflicts?

[XN137]

rebased after trivial merge conflict:

runtime/service/src/test/java/org/apache/polaris/service/quarkus/catalog/AbstractIcebergCatalogTest.java