Unify AppContext handling and make it all trimmable

[marek-safar]

AppContext is useful only for workloads which allow users to alter the execution environment or launch configs but for workloads which don't there should be an option to remove all AppContext logic and use the values known at compilation time.

There are multiple ways how AppContext is handled inside libraries, some use LocalAppContextSwitches others AppContextConfigHelper or call AppContext directly. This should be unified so we can trim all AppContext logic and keep only code path which will be executed.

@eerhardt @vitek-karas

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[CoffeeFlux]

Is this even possible under the current design? The default host passes in a bunch of flags that get threaded through AppContext, and BaseDirectory is also pulled from there.

[vitek-karas]

In theory if everything which reads data from AppContext is hardcoded via substitutions in the linker, it "might" be possible.
I would like to understand what is the expensive part. The part which stores the dictionary of knobs and the API on top of it is relatively tiny. But if there are other parts which are large.. maybe we can come up with some magic.

[marek-safar]

In theory if everything which reads data from AppContext is hardcoded via substitutions in the linker, it "might" be possible.

I don't think that's the right approach. There are already like 50 or more AppContext switches many of them will probably be never set. We probably need some way to recognize that they are not set and propagate the default value.

[vitek-karas]

Does that mean that in for example Xamarin.Android there's literally no code which will ever set any of the internal representation of the AppContext switches?
Maybe a better approach would be to ifdef out the code in CoreLib for Xamarin.Android then.

I might be able to image world where the code is structured such that constant propagation will be able to kick in:
Access to AppContext switches would be only through something like if (TryGet) { return value } else { return false; // default } and if TryGet is ifdefed out to simply return false constant propagation would kick in.

[marek-safar]

Does that mean that in for example Xamarin.Android there's literally no code which will ever set any of the internal representation of the AppContext switches

I don't think there is. There could be AppContext.SetSwitch somewhere in user code but not sure how likely that is and if we should feature-switch it with throw or try to be smart.