[FLINK-10517][rest] Add stability test

[zentol]

What is the purpose of the change

This PR adds a stability test for the REST API to prevent API breaking changes.

The test operates against an API snapshot (created by the test if -Dgenerate-rest-snapshot is set).

One snapshot is created for each RestAPIVersion, each being an array of all supported rest calls.

The test verifies the following:

• URLs are not modified
• Methods are not modified
• StatusCodes are not modified
• file-upload flags are not modified
• set of path parameters is identical
• query parameters are neither removed nor upgraded from optional to mandatory
• fields are not removed request/response bodies nor their type changed (bar some exceptions)

The implementation of these checks can be found in CompatibilityRoutines.

[flinkbot]

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Review Progress

• ❓ 1. The [description] looks good.
• ❓ 2. There is [consensus] that the contribution should go into to Flink.
• ❓ 3. Needs [attention] from.
• ❓ 4. The change fits into the overall [architecture].
• ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.

The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot approve description to approve one or more aspects (aspects: description, consensus, architecture and quality)
• @flinkbot approve all to approve all aspects
• @flinkbot approve-until architecture to approve everything until architecture
• @flinkbot attention @username1 [@username2 ..] to require somebody's attention
• @flinkbot disapprove architecture to remove an approval you gave earlier

[GJL]

The approach of deserializing late is awkward but I do not know a solution yet.

[zentol]

The only solution i see is have a well-defined RestAPISnapshot (i.e. pull the details from the routines in here), but tbh I quite like that every routine is able to freely define it's own container.

[GJL]

I still do not know a solution but I think I should express myself better why I think current approach can be improved:
- RestAPISnapshot looks like domain object but contains raw data that is not deserialized
- two points of deserialization
- deserialization mixed with business logic, i.e., in the compatibility check we deserialize

I think it's fine that every routine defines it's own container, and there should be a way not to scatter the deserialization logic. Unfortunately I am on vacation now, and I cannot give you a definite recommendation on how to proceed as I have not thought this problem through.

[GJL]

I decided that I can live with deserializing the containers late. I think an alternative could be to deserialize eagerly everything as Object with a custom jackson deserializer.

[GJL]

I think overall this looks good. I have left some minor comments.