Support the reconciliation protocol version 1.0-draft

Over at the reconciliation community group, we have been making improvements to the reconciliation protocol. The goal is to make it easier to implement reconciliation services and clients and add missing features. While many of such improvements have been done in a non-breaking way from 0.1 to 0.2, the version 1.0 that we are currently working towards includes a range of incompatible changes (such as the way reconciliation queries are submitted to a service). Therefore, services which currently follow the 1.0-draft specification are currently incompatible with OpenRefine.

Proposed solution

Implement support for the 1.0-draft protocol in OpenRefine, keeping compatibility with version 0.1 / 0.2.

One approach to doing so would be to start by proxying all reconciliation calls from OpenRefine's frontend through its backend (#7185). Once that is done, we could add the logic of supporting the different protocol versions in the backend, meaning that the frontend wouldn't have to know what version is being used.
This compatibility layer in the backend could be a reusable Java library (for instance https://github.com/wetneb/ReconToolkit which I started with this in mind).

Alternatives considered

There are surely other ways to introduce such a support.

Additional context

An overview of known implementations of the protocol and the versions they support can be found at:

• https://reconciliation-api.github.io/testbench/
• https://reconciliation-api.github.io/census/

It's worth noting that, as its name suggests, version 1.0-draft is still being worked on and is therefore a moving target. On one hand it can be worth waiting for it to be stable before implementing it, on the other hand implementing it early is a good way of identifying issues in the specifications and addressing them before the protocol is stable.

The new protocol would be helpful to solve the following issues: #6234, #6053, #6044, #4715, #3139, #2332, #2075

Read the 1.0-draft specification and issue #7185 first, then trace how reconciliation calls currently move between the frontend and backend. Define the compatibility approach around the protocol's version differences; done means OpenRefine supports 1.0-draft while retaining compatibility with 0.1/0.2.