[rust-server] allow @metaswitch to stop maintaining a fork of swagger-codegen

TLDR: we'd like to make some changes to testing/CI for rust-server (and maybe fiddle with htmlDocs2 as well?) to allow us to kill off a private fork we're currently maintaining.

Description

At @metaswitch, we originally created the rust-server generator (see #6613). Since then, we've been contributing new features. Unfortunately, we're starting to discover that the cost of contributing upstream and syncing changes back is getting quite painful.

The problem is that we worked on the rust-server generator for quite a while in a private fork running on a self-hosted GitLab instance. This has meant that our fork has diverged somewhat from upstream, which makes syncing changes back and forth quite painful.

In order to reduce this current burden, I'd quite like to investigate removing the differences that make our fork different. That way, we can develop directly against this project (rather than our fork), and thus get features/fixes contributed faster.

Our current list of differences is:

• We use GitLab CI. As such, our fork has a .gitlab-ci.yml file that builds swagger-codegen and then generates and tests the rust-server sample.
• We've expanded petstore-with-fake-endpoints-models-for-testing.yaml significantly, adding endpoints to test XML/plaintext/form data/UUIDs/security/securityDefinitions
• We've made some changes to the htmlDocs2. Some of these are general improvements that I think we've just not yet got merged. However, some of these are Rust-specific (e.g. adding Rust examples to the generated API docs).

Suggest a fix/enhancement

I think we then probably want to do the following pieces of work:

• Add testing for rust-server to the current maven system, and ensure that they get run by travis. Importantly, this should include verifying that the sample is up to date. This will ensure that rust-server can't get silently broken in future.
• Add a new petstore template containing all the features rust-server supports - petstore-rust-server.yaml, perhaps? The rust-server testing will use this. We can then use this template to add testing for new rust-server features without breaking tests for the other generators.
• Most of the docs differences are straightforward improvements that can get merged across:
  • Bugfixes to cope with schemas with funny chars etc., including: fixes to vendor extension handling, non-JSON-valid model names, duplicate nicknames
  • Render scope information (inexplicably omitted)
  • Fix broken support for "anyOf"
  • Add support for "readOnly" and "x-nullable"
  • Improve formatting of: app description, response descriptions, font loading (the font isn't changed, it's just loaded in a different way)
• We've also extended htmlDocs2 to add a tab with rust-server examples. It might be possible to get this in if we add an option to control whether this is shown (which defaults to 'off').
• Merge across our current backlog of features/fixes:
  • Hyper 11 support - currently blocking the rest, but expected to land shortly.
  • Support for URL-encoded form fields
  • UUID support
  • Fixes to XML support
  • Changes to path handling (I believe the only changes are performance improvements)
  • Split the rust-server template files in a clearer way
  • Some support for generating rust-server examples, including nice formatting

Once that's done, we should be in a position to be able to drop our current fork and develop directly against swagger-api/swagger-codegen without the current amount of git history juggling we're doing in our fork. This should mean that we can contribute with less friction, and will notice sooner if a change to swagger-api/swagger-codegen breaks our usage.

Any thoughts (@frol @farcaller @wing328)? Do the proposed set of changes seem sensible?

Start by reviewing the existing rust-server generator, the current Maven testing system, and htmlDocs2, then compare the listed fork differences with the repository. Done means rust-server testing runs through the Maven/Travis flow, a dedicated petstore-rust-server.yaml covers its supported features, and the agreed documentation improvements are merged.