Updating API Generation

[mettke]

PR for #99

This is the first step for migrating to the openapi spec at https://api.slack.com/specs/openapi/v2/slack_web.json. From this brief first look, I guess that this will be a breaking change. But we will see.

ToDo:

• Parse openapi spec
• Generate modules
• Generate types
• Generate sync methods
• Generate async methods
• Test new API

Notes:

• I tried to use https://crates.io/crates/openapi, however, it is not able to parse the spec from slack. Guess they do not completely adhere to the definition... The types I use were taken from openapi and were modified till they worked...
• I have the problem I'm creating the same types multiple times, because the generator cannot tell that they are the same. Currently I'm solving this using numbers xyz, xyz1, xyz2... Not sure whether there is a better way.
• So far it looks like error messages are sometimes missing. And the error message descriptions are always missing...

[mettke]

@brownjohnf @dvaerum @dten
After quite some efford this is ready for testing. As you @dten said, the openid slack spec is not perfect and requires some corrections, still I'm (so far) quite happy about it.

Any chance you folks have them time to help me testing? Also @dten feel free to have a look to check whether this goes into the right direction.

[dten]

Hey thanks for this gargantuan effort. It's gonna take me a few days to get some time to go through it. 😯😯😯

[rbtcollins]

Three thoughts -

One, merging in scraped results is probably still needed as the OpenAPI specs are super stale.

Two, the 'correct_xx' methods that are empty seem like pure noise: given the use of a wildcard match anyway, I think it would be a much smaller codebase to maintain if only the exceptions were present. e.g. in codegen/src/adapt/admin/apps/mod.rs have fn correct_approve but not correct_restrict. This places no future restriction on such fixups existing in future, but means we don't have a manual set today.

Three, rather than pulling the openapi spec from the web, if we use a git submodule, we could have a fork where these fixes are applied as a patch to the JSON schema directly, rather than in code to the parsed data structure. This might make it easier to maintain and drop them as things get fixed.