[XABT] Use precompiled .dex files when available.

[jpobst]

Context: #9534

We already ship .dex versions for the 3 .jar files that get used in dotnet new android.

• mono.android.dex
• java_runtime_net6.dex
• libSystem.Security.Cryptography.Native.Android.dex

Today these .dex versions seem unused. If we modify D8 to look for a foo.dex next to any foo.jar it's asked to embed, we can use these precompiled .dex files instead.

Using them instead of the .jar variants appears to save ~1.7s on a FastDev build:

Scenario (_CompileToDalvik target timings)	PR	main
Full	2.06 s	3.78 s
NoChanges	not run	not run
ChangeResource	not run	not run
AddResource	1.96 s	3.73 s
ChangeCSharp	not run	not run
ChangeCSharpJLO	1.99 s	3.8 s

Additionally provides $(_AndroidDisablePrecompiledDex) as an escape hatch.

[jpobst]

My biggest concern with this is desugaring. These existing .dex files are all built with --no-desugaring, but theoretically there could exist a .dex file that gets picked up that has been "desugared" and will cause problems on an API-24+ application. Today, it would use the .jar instead of a precompiled dex, so desugaring will be turned off at app compile time, thus using the precompiled .dex file would be a regression.

Maybe this is an extremely unlikely scenario that we can ignore?

This does provide a $(_AndroidDisablePrecompiledDex) opt-out, though a user wouldn't know they need it without our intervention.

[jonpryor]

I wonder if we could/should "encode" the desugar nature into the filename, to prevent inadvertent use. For example, mono.android+desugar=no.jar would have no desugaring, while mono.andorid+desugar=23.jar would be a desugared binary against API-23.

This would still mean that the mono.android.jar that we've previously shipped will not be used, but newer encoded .dex filenames would.

[jpobst]

I wonder if we could/should "encode" the desugar nature into the filename, to prevent inadvertent use.

Yeah, my initial implementation used mono.android.24.dex. This works under the assumption that anything compiled with --min-sdk=24 wouldn't use desugaring.