[WIP] Replace HK2/Types/Parser/Scanner with Jandex and cache in the domain

[lprimak]

Deploy performance improvements

This is an experiment (for now)

This PR achieves at least 1.5X improvement when dependencies are not cached, which is a worst-case scenario.
I have seen as much as 5X performance improvement on a warmed-up JVM with dependencies cached,
with many dependencies.

Feedback is appreciated

Thank you.

Fixes #7079

• Save jandex to transient metadata
• Refactor HK2-Types stuff in WeldUtils into separate file
• Use Jandex in addition to Types in WeldUtils (get jandex-based WAR to deploy) - ignoring dependencies for now
• How does Scanner / Parser parse war-libraries? - what's the calling flow? - in ApplicationLifecycle (kernel)
• Save / cache Types or use Jandex for dep libs? - Jandex
• Index (via Jandex)
• Index via Jandex - WAR dependencies
• Restore shared WARlib functionality
• Cache Jandex indexes in the domain - file cache on disk
• Load Jandex from cache, if exists
• Does old scanner get invoked for WARlibs? - No, scanner doesn't get invoked for warlibs
• DOL Factory using Jandex
• WarScanner using Jandex
• EAR support (DOL module, etc)
• Do not cache -SNAPSHOT dependencies
• DOL: remove handler stack, make it no-op
• Sync w/main branch
• Profile the code, see where the bottlenecks actually are
• Check default context push / pop
• Re-introduce parallel scanning. Hopefully causes much more performance improvement
• Delay writing jandex cache to disk until after deployment
• Check for file leaks
• Check for ClassLoader leaks
• Check new SpringBoot-related code and remove types from there / cc: @Pandrex247
• Emailmanager doesn't deploy on remote container
• Remove AnnotationClassModel and use Jandex-based model directly
• Test / fix issue-reproducers/cdi-unknownbda reproducer
• Get FlowLogix tests to work
• Check old lifecycle to see if anything is missing that needs to be restored
• Remove APF/hk2 folders (old lifecycle)
• Code cleanup
• Get tests to pass again

[svendiedrichsen]

You might want to avoid spreading the JBoss classes like i.e. Index around in the Payara codebase.

[lprimak]

Index is kinda the whole point of this PR.
The issue is that current annotation scanning framework is not made for CDI, is slow, and can't be cached.
Jandex is a small, separate project, has no dependencies, and is tailor made for CDI.
While it did come from JBoss, it's no longer embedded in that ecosystem and can be used unencumbered.

Any effort to isolate Index class will result in an unnecessary wrapper that would not add any value.

Do you have a specific suggestion? Am I missing something?

[svendiedrichsen]

It would result in a wrapper class. I agree. But I would call it a useful one. It allows to control and limit the interface towards payara code and allows to switch technology if needed/wanted.

[svendiedrichsen]

And you could have convenience methods useful for payaras interaction with the index.

[lprimak]

Let's see where this goes... I think it's only used in one place anyway