fix(otlp-exporter-base): remove usage of require in esm/esnext builds

[EmrysMyrddin]

Which problem is this PR solving?

ESM and ESNEXT builds are broken, because they contain the usage of require function to dynamically import packages.

Short description of the changes

This PR is replacing the require call with an import one. The only problem of this is that it is now asynchronous.

But this is not a problem since we can change the return type of the method (it is a private method), and the caller is already async.

The only difficulty is to make sure there is no parallel loading happening.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

I've tested it on my local project which was bundling an ESM Node application with Rollup.

Checklist:

• Followed the style guidelines of this project
• [ ] Unit tests have been added Not relevant, this PR doesn't add anything
• [ ] Documentation has been updated Not relevant, it is purely internal changes

[linux-foundation-easycla]

• ❌ - login: @EmrysMyrddin / name: Valentin Cocaud . The commit (e021e68, 00a06f5) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[raphael-theriault-swi]

This was previously attempted in #5220 but the changes require the test runner configuration to be adjusted for tests to work. I'm currently figuring out a way to make it work in #5719 which also includes the changes you're making here, which should hopefully fix your problem :)

[EmrysMyrddin]

Oh ok, It's my first time trying to POC around this code base ^^'
I searched for an open issue, but didn't thought about looking at closed PRs !

I haven't looked at how tests are made, since I wasn't expecting having to update tests for this PR :-P So not quite sure to understand how this change does break the setup ^^'

I will follow your PR then ! Do you want me to close this one ?

[cjihrig]

Has anyone looked into using module.createRequire(filename) as an option to keep require() working without moving to async logic?

[EmrysMyrddin]

I'm not sure how much this would be compatible with web/non node runtimes

[JacksonWeber]

If dynamic import fails you may want to add catch logic to handle the resultant error.

[EmrysMyrddin]

It was not handled before, so to maintain the same behavior, I don't catch any error.
The rejected promise will be handled by the caller of send function if it needs to be handled.

[EmrysMyrddin]

closing in favor of #5719 which is fixing this and have working unit tests :-)