Replace Jackson DataformatYaml with SnakeYaml

[agrgr]

No description provided.

[agrgr]

@tim-aero, this dependency has another branch for versions 3.0+ (relocated to tools.jackson.dataformat:jackson-dataformat-yaml) with the future support, the current branch has LTS but will eventually discontinued at some point. The 3.0+ versions require Java 17+, are there any plans to update Java Object Mapper to support it?

[agrgr]

@tim-aero, another question is whether we should use SnakeYAML directly (which continues to support Java 8). If yes, we will need to check what to rewrite and how feasible is that.

[tim-aero]

It looks like organizationally we're moving towards SnakeYaml, we probably should see if moving this to SnakeYaml is easy while we're touching it anyway.

[agrgr]

@tim-aero, the replace is done.
It should be noted that any downstream consumer whose code says catch (JsonProcessingException ...) or catch (IOException ...) around a withConfiguration(String, ...) call will get a compile error (a checked exception that no code path can throw).

So far the cleanest solution looks like accepting the break, maybe additionally documenting it. SnakeYAML throws YAMLException, which is unchecked. Dropping the checked exception looks as a natural outcome of the migration. If we do this together with bumping the version and documenting the breaking change of exception type, zero code changes needed.
An alternative would be catching YAMLException and re-throw as IOException. This keeps callers who previously caught IOException (the parent of JsonProcessingException) have it working without modification. Callers who specifically caught JsonProcessingException (not just IOException) would still have a breaking change.

Other than that, there is jackson-databind dependency used in tests only, previously it was a transitive dependency brought by Jackson DataformatYaml. So far I left it without replacing, theoretically it can be replaced with Gson or perhaps something else, or maybe with a native solution which will likely require more changes.

[tim-aero]

Looks good to me.