POC: Code gen type aliases

[marefr]

What this PR does / why we need it: It's been historically hard to put certain types/logic in a separate package in the SDK if that separate package depends on the backend package which create a cyclic dependency.

With #1019 I really wanted to put the most middleware logic in a separate package, but I couldn't due to cyclic dependencies.

With #1101 adding a new middleware to be shared with both SDK and Grafana would have make sense to put in a separate package, but again I couldn't due to cyclic dependencies. Adding these exported types to the backend package that normally plugin authors shouldn't have to use or care about doesn't feel optimal.

With #1106 we successfully explored/used type aliases to move certain structs, const and functions from the backend package to a separate package while keeping backward compatibility using type aliases for types and const and functions calling the respective const and function in the new package.

In an attempt to make the life easier for SDK maintainers and plugin authors this proposes a way to generate type aliases from a certain package into another package, in this example all "contracts" was moved to a contracts package from the backend package and then code generation generates contracts_gen.go in the backend package which is basically a mirror of any exported type in the contract package.

For SDK maintainers, some changes earlier made in the backend package is now done in the contracts package followed by running codegen.

For plugin authors, there shouldn't be no change.

Which issue(s) this PR fixes: Fixes #

Special notes for your reviewer:

• It seems to work (https://github.com/grafana/grafana/pull/95046), but the codegen code is a bit of a mess currently.
• Codegen not currently automatically running

[andresmgot]

maybe a generic thought, what's the problem of having all the related logic in the same package? If there is no clear distinction between packages, I don't see the problem of making backend bigger? I'd be worried that adding code-generation adds more complexity than what it solves.

[marefr]

maybe a generic thought, what's the problem of having all the related logic in the same package? If there is no clear distinction between packages, I don't see the problem of making backend bigger?

It's a fair point. I discussed this in the description, mainly "Adding these exported types to the backend package that normally plugin authors shouldn't have to use or care about doesn't feel optimal."

I'd be worried that adding code-generation adds more complexity than what it solves.

It definitely does and is a trade-off to keep in mind

[marefr]

Closing for now since no direct interest, but could be picked up in the future if needed