NativeAOT support for GarnetServer

[neon-sunset]

This PR makes progress towards supporting NativeAOT publish of GarnetServer. For now, NativeAOT support for the nuget itself is out of scope as I suspect the users first and foremost care about the application itself.

If the size of PR gets too large, it may be split into multiple as there are a few areas that need to be refactored to be AOT-compatible:

• Custom "configuration binder" for Options and RedisOptions
• Options validator
• ArrayCommands

Ideally, it should overall improve the state of codebase as there are existing tools like System.CommandLine or M.E.C.ConfigurationBinder (or similar) which provide the features required by Garnet in a more robust, trim and AOT compatible way.

[neon-sunset]

@microsoft-github-policy-service agree

[TalZaccai]

Hey @neon-sunset! Thanks for your willingness to contribute to Garnet!

I'm not sure if what you're suggesting here is possible to support, as we do support custom commands that are dynamically loaded from local dlls on the server (See RespServerSession.RegisterCustomCommands in Garnet.server/Resp/ArrayCommands.cs).

Let me know what you think!

Tal.

[PaulusParssinen]

It maybe possible to introduce a compile time feature-switch for the custom command support, which can be enabled by default but toggled by the developers who want the AOT benefits.

I haven't investigated how much work introducing such switch would be in Garnet's case but the feature switches are common approach in .NET to toggle some functionality that can't be trimmed. The .NET runtime itself uses such feature switches, for example, to disable and trim reflection stack in its entirety.

edit: Nevermind, above would be approach for any features in the NuGet libraries that are hard to trim.

For the Garnet.Server, we could introduce the option to disable custom command as command-line switch (again opt-in presumably) and guard the custom command logic with RuntimeFeature.IsDynamicCodeSupported? This should allow building and packaging separate AOT compatible server binary 🤔

[neon-sunset]

@TalZaccai @PaulusParssinen Indeed, I was mostly going over the list of trim and AOT warnings, and either addressing them or writing down for future work.

Yes, it makes sense to guard the dependent loading with a check and add an informative error else clause when NAOT is targeted. Once NAOT binaries are published and released, there could simply be a notice regarding JIT-dependent feature(s). I don't think it makes sense to add a toggle to explicitly disable this feature for JIT deployment too, or at least, if that is still desired, it can be done separately. I will continue to work on this a little bit later, thank you for the assistance :)