Set up API client code generation

[michpohl]

This PR adds the main code generation setup to :tidalapi, as well as the generated files.

Please review commit by commit to have an easy overview, and just skip the commit adding the generated files 😄

Note for reviewers:

The code in this pull request is a MVP. Please point out anything you don't like, but the idea is to get this one merged and then improve what needs improving in subsequent PRs. So if you request changes it should be for things that absolutely can't go in like this.
Please also look at the additional info provided in the commit messages.

Note about the generated code:

I debated whether it should be in the src folder or not, but after some reading I decided yes, because:

• We will commit the generated code
• Generation will not happen as part of the normal build process
• Generated code in the future will be changed and reviewed via PR.

How can you test this?

1. Check out the branch
2. Publish to MavenLocal
3. Add MavenLocal in settings.gradle.kts like this:

dependencyResolutionManagement {
    repositories {
        mavenCentral()
        }
}

4. Add a dependency to com.tidal.sdk.tidalapi:0.1.0 where you want to use it, and instantiate an api client like this:

 val client: TidalApiClient = TidalApiClient(credentialsProvider)

5. Play around with it.

Do you need to test it to review this?

At this stage, no imho. But if you like to, feel free!

How to/ test code generation?

As you currently need a binary of my fork of openapi-generator, ask me personally, if you want to play around with it.
But after this PR, we wil quickly move towards making this available via GH Actions, which will simplify this all.

[michpohl]

Note that ktlint cannot fix these imports (* imports of types provided by us), so after it is run, we manually remove them anywhere they show up as we don't need them, but openapi-generator just puts it everywhere

[michpohl]

This would point to where the executable would be found. As I still work on providing it, it is tbd for now (which means, if you run the python script, it will download and merge the API schemas, but won't (re-) generate the code).

[e-kononenko]

Why was it required for you? Would a simpler approach (just process all files one by one and overwrite models) like we did on iOS not work here?

[michpohl]

I feel like I answered this already, but the answer got lost.
In short: I generate interfaces for each place a oneOf item is used - and those places are distributed across all APIS. So if I generate them consecutively, each generation overwrites code I just created. That's why the generator needs full context before run.

[stoyicker]

I don't see why we would want to commit the generated code. It sounds more reasonable to me to generate it on CI on publish, put it in the published binary and that's it.

[michpohl]

I don't see why we would want to commit the generated code. It sounds more reasonable to me to generate it on CI on publish, put it in the published binary and that's it.

There are a number of reasons for it, here are some:

1. We want engineers to easily review the changes in generated code before merging
2. We want to keep open the ability to manually change details before merging, if needed
3. API code generation (especially on Android, where we needed to alter the generator) is still quite brittle, and the schemas are still in a phase where they might change quite significantly. This approach makes it easier to step in and apply quick fixes

I know that you added a similar comment on my earlier PR, and I would have liked to do it that way too. I did a good amount of work towards that goal. But this approach made the most sense to thew devs involved (not just for Android) and so we decided to go with this way.

However, once we are past an MVP situation and both schema design and client use have stabilized it might be nice to revisit the approach and maybe reconsider/improve, but currently this is the way to go.