Versioned combinators and access_role changes in V3

[pcapriotti]

This PR introduces VersionedReqBody and VersionedRespond combinators for Servant and some V3 changes to the access_role field in conversation endpoints. The versioned combinators are used to select different instances for different versions, while keeping the handler types intact.

This supersedes #2741, which had diverged too much to be sensibly rebased or merged.

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

[jschaul]

This is very abstract and could benefit from concrete examples of a timeline including multiple backend and client releases, and at which point changes occur. The way I currently read this is "The backend can make incompatible event changes as long as the client can deal with both the old format and the new format". That just moves the burden of backwards compatibility from the server to the clients, which is not ideal as old versions of clients are around for much longer than old versions of the backend. What am I missing?

[pcapriotti]

Well, the access_role change in this PR is an example of change X.

I added an example timeline. Not sure it adds anything useful, though, as it's mostly restating the same things with example numbers instead of N and Q.

That just moves the burden of backwards compatibility from the server to the clients, which is not ideal as old versions of clients are around for much longer than old versions of the backend. What am I missing?

The burden of backwards compatibility is shared with this system, and goes away after some time. At first both the backend and the clients have to support two formats. At some point in the future, one of the two can drop the old format. And finally the other one can drop it as well. In fact, the system is pretty symmetric wrt backend and clients.

I agree that it would be nicer to properly version events, but that seems to be quite a major undertaking, and might have some performance implications. This requires some extra bookkeeping, but ultimately achieves the same effect of getting rid of legacy code from all code bases, which is the ultimate goal anyway.