Upgrade com.fasterxml.jackson library to 2.13.3

[alexopoulos7]

Fix for issue #241

[alexopoulos7]

Updating fasterxml library to 2.13.3
Trying to fix: https://cwe.mitre.org/data/definitions/502.html

Here for more comments:
https://www.cybersecurity-help.cz/vulnerabilities/49367/

[dmikurube]

@alexopoulos7 Thanks for your contribution!

But sorry and unfortunately, we are not able to merge this immediately. This is because :

• Embulk's core has had its own dependencies on Jackson core, databind, and annotations 2.6.7. Those are actually used even in Embulk plugins (until Embulk v0.10.31).
• Embulk plugins have assumed that the Embulk core has its own Jackson dependencies. The Embulk core is loaded by the parent class loader, then, the core's dependencies are visible to plugins. Some Embulk plugins have depended some additional dependencies on some extra Jackson librarires (ex. jackson-dataformat-xxx), kept with the same version 2.6.7.
• The situation has caused a complicated situation of mutual locking. Once the Embulk core upgrades its own Jackson, some plugins would run with mixed Jackson versions. Once a plugin upgrades its own Jackson, the plugin would run with mixed Jackson versions, too. Mixing Jackson versions could cause unexpected problems.

This is why we have kept Jackson versions such old so far. We're trying to resolve this problem fundamentally, through the "development" series, Embulk v0.10.

It was definitely a bad design. But we had to fight with it because the Embulk eco-system was already established when I took it over.

See:

• https://dev.embulk.org/topics/get-ready-for-v0.11-and-v1.0.html

---

The v0.10 effort needs a lot of plugins to "catch-up", and we've spent much time on the catch-ups.

After the catch-up, the Embulk core would have its own Jackson which is invisible to plugins, and plugins would have their own Jackson which are not interfered by the Embulk core. The core and plugins would be able to upgrade without any mutual locking.

We are aware of the vulnerability, of course. But after investigating it, we concluded that normal use-cases of Embulk are not highly impacted by it. Then we decided to keep it until the catch-ups and v0.10 are done.

Sorry for taking time on it. The catch-up has taken much longer time than expected, but I believe we're close to the goal...