feat: add synthetic service provider

[paullatzelsperger]

What this PR changes/adds

Adds a "synthetic" extension, whos job is solely to declare a @Provides list for the Monitor, TypeMAnager, Clock and Telemetry, all of which are services that are instantiated in a special way.

Why it does that

Avoid cyclic dependencies

Further notes

• I opted for adding the SyntheticExtension and then removing it again, because that seemed to have the least impact on the code base while at the same time satisfying the dependency resolution mechanism.
• The SyntheticExtension is not needed outside of dependency loading, which is why I chose not to instantiate it through the service loader and I removed it again right after the topological sort went through.
• The ServiceExtensionContext is used as fallback: whenever a feature cannot be satisfied through normal dependency resolution, we check if the context already has that service registered, in which case no error is thrown.
• Another option would have been to add those services directly into the dependency map (see next snippet), but that seems less flexible and heavy-handed and error-prone:

    public List<InjectionContainer<ServiceExtension>> of(List<ServiceExtension> loadedExtensions) {
        var extensions = sortByType(loadedExtensions);
        var dependencyMap = createDependencyMap(extensions);
        addStandardServices(dependencyMap);
        // ...
    }
  
    private void addStandardServices(Map<String, List<ServiceExtension>> dependencyMap) {
        dependencyMap.put(Monitor.class.getName(), emptyList());
        dependencyMap.put(TypeManager.class.getName(), emptyList());
        dependencyMap.put(Clock.class.getName(), emptyList());
        dependencyMap.put(Telemetry.class.getName(), emptyList());
    }

Linked Issue(s)

Closes #2372

Checklist

• added appropriate tests?
• performed checkstyle check locally?
• added/updated copyright headers?
• documented public classes/methods?
• added/updated relevant documentation?
• assigned appropriate label? (exclude from changelog with label no-changelog)
• formatted title correctly? (take a look at the CONTRIBUTING and Etiquette for pull requests for details)

[paullatzelsperger]

@ndr-brt after talking with @jimmarino I think there is a better way than instantiating an "artificial" extension: we could just use the ServiceExtensionContext as fallback in case a dependency is not satisfied. That way no special treatment is needed.
My last commit displays this.

[codecov-commenter]

Codecov Report

Base: 64.47% // Head: 64.57% // Increases project coverage by +0.09% 🎉

Coverage data is based on head (89a3586) compared to base (7c62610).
Patch coverage: 90.47% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2373      +/-   ##
==========================================
+ Coverage   64.47%   64.57%   +0.09%     
==========================================
  Files         839      842       +3     
  Lines       17390    17491     +101     
  Branches     1048     1054       +6     
==========================================
+ Hits        11213    11295      +82     
- Misses       5744     5761      +17     
- Partials      433      435       +2     

Impacted Files	Coverage Δ
...ipse/edc/connector/core/CoreServicesExtension.java	93.93% <ø> (ø)
...g/eclipse/edc/boot/system/runtime/BaseRuntime.java	78.46% <50.00%> (ø)
...a/org/eclipse/edc/boot/system/DependencyGraph.java	98.63% <94.44%> (+0.10%)	⬆️
...a/org/eclipse/edc/boot/system/ExtensionLoader.java	87.17% <100.00%> (ø)
...clipse/edc/iam/oauth2/client/Oauth2ClientImpl.java	83.33% <0.00%> (-7.30%)	⬇️
.../org/eclipse/edc/junit/testfixtures/TestUtils.java	33.84% <0.00%> (ø)
...nector/api/management/asset/AssetApiExtension.java	100.00% <0.00%> (ø)
...transferprocess/store/SqlTransferProcessStore.java	0.00% <0.00%> (ø)
...ment/transferprocess/model/TransferProcessDto.java	100.00% <0.00%> (ø)
... and 12 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[ndr-brt]

@ndr-brt after talking with @jimmarino I think there is a better way than instantiating an "artificial" extension: we could just use the ServiceExtensionContext as fallback in case a dependency is not satisfied. That way no special treatment is needed. My last commit displays this.

Looks good to me, so can we get rid of the SyntheticExtension?

[paullatzelsperger]

@ndr-brt after talking with @jimmarino I think there is a better way than instantiating an "artificial" extension: we could just use the ServiceExtensionContext as fallback in case a dependency is not satisfied. That way no special treatment is needed. My last commit displays this.

Looks good to me, so can we get rid of the SyntheticExtension?

yes of course, forgot to delete, thanks.

[github-actions]

This pull request is stale because it has been open for 7 days with no activity.