Increase refcount to ze_loader/CUDA libraries when Level Zero/CUDA providers are used

[vinser52]

Description

Prior to this PR, the Level Zero provider did not dlopen(“libze_loader.so”) at all. We suppose that UMF’s client, who uses Level Zero provider, loaded libze_loader.so into the process. But what if there are two clients in the process:

1. The first client loads libze_loader.so into the process and uses the Level Zero provider. In that case, UMF inits Level Zero symbols via dlsym. Then the first client destroys the Level Zero Memory provider and unloads the libze_loader.so.
2. Then the second client loads libze_loader.so into the process and uses the Level Zero provider. But our current implementation does not catch such situation and Level Zero symbols are considered initialized, but the dlsym should be done again.

This PR fixes that. The UMF acquires handle to the libze_loader.so via dlopen. There is a RTLD_NOLOAD flag that tells dlopen not to load the library and succeed only if the library is already loaded. It allows to increase the refcount to the libze_loader.so and not unload it when the first client calls dlclose.

This PR should fix the #926.

Fixes: intel/llvm#16944 (confirmed by @ldorau)

Checklist

• Code compiles without errors locally
• All tests pass locally
• CI workflows execute properly
• New tests added, especially if they will fail without my changes
• All newly added source files have a license
• All newly added source files are referenced in CMake files

[bratpiorka]

I know this is probably not easy, but could we add the simplest test for this case?

[vinser52]

I know this is probably not easy, but could we add the simplest test for this case?

yeah, I am working on it, that's why this PR is a draft.
Also, I will take a look into the CUDA provider, I believe it requires the same changes.

[ldorau]

@vinser52 @bratpiorka @pbalcer This PR fixes intel/llvm#16944

[vinser52]

I know this is probably not easy, but could we add the simplest test for this case?

Ok, new tests have been added. Actually, I split the umf-provider_level_zero_dlopen and umf-provider_cuda_dlopen to the umf-provider_level_zero_dlopen_global/umf-provider_level_zero_dlopen_local and umf-provider_cuda_dlopen_global/umf-provider_cuda_dlopen_local tests correspondingly.

Without my changes the umf-provider_level_zero_dlopen_local and umf-provider_cuda_dlopen_local tests are failed.

[vinser52]

@vinser52 @bratpiorka @pbalcer This PR fixes intel/llvm#16944

so this PR is ready for the review.

[ldorau]

@lukaszstolarczuk @bratpiorka @pbalcer Hanging on Windows CUDA CI builds ...