4.x: Helidon Inject - only API dependency to compile

[tomas-langer]

The current implementation requires runtime to be present at compilation time (through dependencies of the generated code).

This should be changed, so only API is required.

Planned changes against the inject-update branch in Helidon repository:

• 7957-inject-updates-4 - introduce new inject modules
• 7957-inject-updates-5 - maven plugin and required changes to build
• 7957-inject-updates-6 - refactor all modules to use new modules
• remove modules that are no longer needed
• review bom pom
• 7957-inject-updates- - refactor existing inject processors to use codegen (such as Fault tolerance) - not needed, does not exist
• 7957-inject-updates-7 - example with services and application plugin - simplify usage for users (4.x: Inject update bigger changes #8186)
• 7957-inject-updates-8 - documentation

[tomas-langer]

An attempt will be done to have this backward compatible (by keeping the bind methods available and deprecated).

The new approach is being designed as follows:

1. ServiceDescriptor will be code generated - this type will depend only on API, and will use class model to be generated
2. The runtime will pick up the generated service descriptors using a module (similar to what is done right now) by binding the descriptors to the binder
3. Then an appropriate service provider will be discovered (through service loader, using an ID that is code generated together with the service descriptor (default is a default method on the interface)
4. These implementation take care of all the lifecycle tasks (activation, deactivation etc.)

Most of the code is either re-used or copied from existing implementation, with focus on:

• null is never used in APIs
• using final fields as much as possible (with the exception of state related fields, such as status, serviceInstance etc.)
• keep service sources as they are right now (e.g. user's code is not modified when creating a service, the generated code and injection runtime code is going to change)
• the concepts remain - source code generated, analysis of the world to make sure all injection points are satisfied, the capability to generate an application class that explictly binds injection points to service providers to prevent runtime discovery

[tomas-langer]

Some conceptual changes are required to align with Helidon style and coding guidelines.
The PR will contain appropriate readme, high level info:

• there will be a new root module codegen to contain all tools related to code processing and generation, with implementations for annotation processing (APT) and classpath scanning (scan). Scan is expected to be used from maven plugin(s), and possibly from command line tools. We could also have a reflection based implementation of these if ever needed
• this results in using codegen instead of processor in most cases (change in modules)
• class model is moved to codegen
• Helidon copyright module is moved to codegen
• tools module is removed

[trentjeff]

You need to add a dependencies-test making use of the enforcer plugin to ensure that there is no inject runtime in the cp. This is to avoid regressions in this area.