WIP: add a new plugin base decoupled from the sdk

[dyladan]

This new plugin base is completely decoupled from the SDK and relies only on the API. After #1448 plugins using this base class will be able to be fully standalone, and will support instrumenting modules very early in the load process, even before the tracer provider is set up.

• Solves load order issue
• Solves yarn pnp issue by using a more direct dependency model
• Removes need for plugin manager
• One instrumentation can patch multiple modules
• Can use different plugins for different versions of a module
• Supports tracers and meters

[obecny]

overall lgtm, one question is this only for node ? If so maybe name should have node word otherwise the semver usage should be moved to platform folder

[obecny]

we are basically not using get/set approach in our sdk so would rather have getTracer, getMeter to just unify all , WDYT ?

[dyladan]

overall lgtm, one question is this only for node ? If so maybe name should have node word otherwise the semver usage should be moved to platform folder

So far I have been focusing on node but I hope that the module will eventually be useful for both web and node.

[vmarchaud]

looks fine 👍

Another question that comes though my mind is since the API is changed a bit, how do handle old plugin loading AND new ones ? Or there will be a breaking change here ?

[dyladan]

looks fine 👍

Another question that comes though my mind is since the API is changed a bit, how do handle old plugin loading AND new ones ? Or there will be a breaking change here ?

The new plugin loader depends on API only, so it doesn't actually depend on any plugin load mechanism at all so the old plugins will still work. I think for now this will just be an alternative plugin load mechanism, then when all plugins have been migrated we can remove the old plugin loader.

[obecny]

I think this can be closed already @dyladan