EDC client handle multiple Digital Twin Registries and Digital Twins

[dsmf]

As User,
I want that the EDC client handles multiple DTRs as described in the concept,
so that we consider all data available by a data provider.

Hints / Details

This story is meant to implement the remaining scenarios from #214, because #214 turns out to be much more complex than estimated. Splitting #214 is necessary because another story in the sprint (#354) depends on the scenarios already implemented in #214.

Remaining scenarios:

1. EDC with multiple DTRs (see EdcSubmodelClientImpl: the contractNegotiationService.negotiate is executed only for one catalogItem at the moment, see findFirst)
2. Multiple EDCs with multiple DTRs (see EdcSubmodelClientImpl: the contractNegotiationService.negotiate is executed only for one catalogItem at the moment, see findFirst)
3. Special scenario: Same DT in multiple DTRs

Concept:
https://github.com/eclipse-tractusx/item-relationship-service/blob/main/docs/concept/TRI-1576-Handling-of-assets-multiple-dtrs/Discovery-process-DTR.md

Outcome / Acceptance Criteria

Outcome

• ...

Acceptance Criteria

• The remaining scenarios described above are implemented

Out of Scope

• ...

[dsmf]

• Updated documentation

  • Added detail diagrams for the scenarios under src/docs/arc42/cross-cutting incl. code references as code comments
  • Improved glossary
    • Added entries for CatalogItem, Contract Offer, Shell
    • Added explanation for DT in glossary
  • Added code comments for better comprehensibility and for making mapping to documentation easier
    • in DigitalTwinDelegate#process findFirst
    • in DecentralDigitlTwinRegistryService#mapToShellId
    • in the detail diagrams

• Implementation and test

  • getEndpointReferencesForAsset in EdcEndpointReferenceRetriever and EdcSubmodelFacade return List<CompletableFuture<EndpointDataReference>> now instead of one EndpointDataReference
    • correspondingly queries all DTRs now instead of first one only (see EdcSubmodelClientImpl.getEndpointReferencesForAsset)
    • this included required change in exception handling
    • other related places in call hierarchy adjusted correspondingly
    • tests adjusted correspondingly
  • DecentralDigitlTwinRegistryServiceTest#FetchShellsTests#whenInterruptedExceptionOccurs checks that current thread interrupted now
  • DecentralDigitalTwinRegistryServiceWiremockTest: Added tests that cover main part of the scenarios
  • Fixed incomplete abstraction from cache implementation which resulted in superfluous dependency and hard to read code
    • EdcSubmodelClientImpl accessed cache for EndpointDataReference both via EndpointDataReferenceCacheService and EndpointDataReferenceStorage previously. Now the cache is only accessed via EndpointDataReferenceCacheService both for read and write. This included changing some test setup:
      • Fixed test setup in SubmodelFacadeWiremockTest
      • Fixed test setup in EdcSubmodelClientTest
    • In this context we discovered that there are no timeouts for some future.get calls which can lead to hanging jobs and increasing resource consumption. Created PBI for this: Missing timeouts can lead to hanging clients and ressource exhaustion #448

Pull Request 775 (Closed in favor of PR to eclipse-tractusx below)

Pull Request to eclipse-tractusx

[dsmf]

Ready for PO-Review @jzbmw