[FLINK-8986][e2e-test] Flink end to end test REST API

[walterddr]

What is the purpose of the change

Adding end to end test for REST APIs for FLIP-6 generated endpoints.

• This is a follow up PR based on [FLINK-8986][e2e-test][WIP] Flink end to end test REST API  #5849 and the changes & improvements are based on @zentol 's comment and suggestions.
• This PR depends on one commit in [FLINK-8985][e2etest] initial support for End-to-end CLI test, excluding YARN test #5863 (ea12737)

Brief change log

• Adding in flink-rest-api-test module and test_rest_api.sh for end-to-end testing
• Adding in payload YAML file for endpoints used by REST APIs if any POST/PATCH endpoint requires a payload.
• Adding a validation sequence before testing REST API modules in order to extract all path / query parameters for REST API endpoints.

Verifying this change

This test is run successfully against all REST API in DispatcherRestEndpoint.

This test will automatically pickup new endpoints for testing as long as support is added to DispatcherRestEndpoint.

If new endpoint requires additional path / payload / query parameter, test will be skipped instead of failing for the new endpoints.

Does this pull request potentially affect one of the following parts:

No

Documentation

No documentations for this test.

[tillrohrmann]

Thanks for creating this PR @walterddr and sorry that it did not get the attention it deserved.

Rethinking the issue a bit I am now a bit unsure whether we should add the REST tests as e2e tests. Given the problems we had in the past with the bash based e2e tests, it might be more maintainable to write these tests as integration test cases. Hence, I would propose to close this PR. Sorry that I did not mention this consideration earlier.

[flinkbot]

CI report:

• 2886c22 Travis: PENDING

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run travis re-run the last Travis build
• @flinkbot run azure re-run the last Azure build

[walterddr]

@tillrohrmann I almost forgot about this :-) yes, totally agree. I think it makes sense to do so in the ITCase path. (I had once try to rebase this PR onto a later release and there were a lot of problems)