keep github connector but automate it with dex-operator

[weatherhog]

• add github provider to dex-operator
  • check if WC case works via several callback URIs
  • get app
  • get apps age
• alert if needs to be created /renewed
• implement app-manifest-flow (related: Improve dex operator credential management #1764 )
• get cluster domains for github in opsctl create dexconfig #2197
• allow github group
• https://github.com/giantswarm/giantswarm/issues/26337
• remove old giantswarm github connector #2269

[anvddriesch]

we tried this out and don't see it being useful to automate github / keep using as idp due to the following limitations

• github api does not support creating and deleting oauth apps (reference)
• there is a limit of 100 oauth apps in github and we are almost there (reference)

we have been thinking about managing existing configuration with dex-operator until removing github. However, this also doesn't seem to be a good return on effort.
The reason being:

• managing one existing oauth app per one MC would only allow logging into the MC itself and not WCs (limit of one callback URL, limit of oauth apps as seen above)
• although key rotation would be automated, we would also have to manage the key for dex-operator itself so the ratio of automatically rotated keys to manually rotated keys would stay the same.

We think that it would make sense to add another idp first and then once we have two idps configured, we can phase out the existing github configuration.

[anvddriesch]

I tried out creating a github app instead of an oauth app and with the right permissions and settings it can be used just the same. (In fact, it's a lot more verbose)
This type of app is also possible to create via the github API https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28#create-a-github-app-from-a-manifest
For this reason I suggest we migrate to github apps and let them manage by dex operator.

[weatherhog]

During refinement we commited on automatic github as dex connector for the future