Kotlin linting

[madsboddum]

Requirements

• It should run as a part of the CI/CD pipeline, so contributors can get fast feedback relating to code style on their pull requests. This also saves the reviewer(s) from having to point out any potential issues.
• IntelliJ and the linter should have the same formatting configurations, so the Kotlin outputted by IntelliJ is formatted as the linter expects. Ideally, the two even read the same configuration file, but this might not be possible.
• Optional: It would be nice if all the existing code doesn't have to be formatted in order for the CI/CD pipeline to be happy. The diff would be absolutely massive and will inevitably cause merge conflicts. Some linters support a "baseline", where existing issues are ignored.

Inspiration:

Kotlin linter: https://pinterest.github.io/ktlint/0.50.0/ There's a Gradle plugin for it: https://github.com/JLLeitschuh/ktlint-gradle

This linter supports .editorconfig files, which IntelliJ can export its code style as.

There's also a GitHub action: https://github.com/marketplace/actions/github-action-for-ktlint ... which can apparently generate annotations where the issues are.

This Action generates annotations from ktlint Report XML.

[madsboddum]

We could also consider running the IntelliJ inspections. The benefit is that these are already very integrated into the existing workflow locally, and the same settings can be shared with the CI/CD pipeline.

We would need to either bring down the amount of inspection problems in the codebase to 0 or only include new inspection problems somehow. The latter is much more difficult, and we should want to have a codebase free of inspection problems anyway.

This could lead to either inspection profile tweaks or code changes.