[SCP-184] Fix incompatible library check when there's no libruby.so

[ivoanjo]

What does this PR do?:

Add a missing check for a NULL result of dlsym that happens when Ruby is not built with libruby.so.

Motivation:

The logic in ddtrace_profiling_loader.c follows Ruby's dln.c; see the big comment at the top of the former for why it needs to exist.

The incompatible_library sanity check exists to try to catch situations where the library being loaded is linked to a different libruby.so (or equivalent in other OSs) than the one that is doing the loading.

BUT when we implemented incompatible_library we missed an check that upstream Ruby does.

From https://github.com/ruby/ruby/blob/v3_1_2/dln.c#L295:

static bool
dln_incompatible_library_p(void *handle)
{
    void *ex = dlsym(handle, EXTERNAL_PREFIX"ruby_xmalloc");
    void *const fp = (void *)ruby_xmalloc;
    return ex && ex != fp; // ⬅️ HERE!
}

Ruby actually checks that the symbol found is not NULL (e.g. with the ex && check). This is important, because there's a valid situation in which the symbol is expected to be NULL: when Ruby is built with --disable-shared at compilation time.

What --disable-shared does is that it builds the Ruby VM logic inside the ruby executable itself INSTEAD OF splitting the logic between the ruby executable and the libruby.so shared library.

To properly support this configuration, we should, like upstream Ruby does, consider a library compatible if the symbol lookup returns NULL.

Additional Notes:

Here's a few ways of telling if there's a libruby:

• RbConfig::CONFIG['configure_args'] will contain --disable-shared
• RbConfig::CONFIG['LIBRUBY'] will be libruby-static.a instead of, for instance libruby.so.3.1.1
• Ruby will not be linked to libruby:

  # with libruby
  $ ldd `which ruby` | grep libruby
    libruby.so.3.1 => /usr/local/lib/libruby.so.3.1 (0x00007fb37e260000)
  
  # without libruby
  $ ldd `which ruby` | grep libruby
  (no output)
  

How to test the change?:

I couldn't find a prebuilt docker image that had Ruby compiled with --disable-shared.

To reproduce the issue, I downloaded the latest Ruby version, configured it with ./configure --disable-shared, compiled and installed it, and then installed dd-trace-rb, and tried to start the profiler.

Without this fix, profiling did not work, I would get:

W, [2022-08-31T10:41:11.727931 #67946]  WARN -- ddtrace: [ddtrace] Profiling was requested
but is not supported, profiling disabled: There was an error loading the profiling native
extension due to 'RuntimeError Failure to load 
ddtrace_profiling_native_extension.3.1.2_x86_64-linux due to library was compiled and linked 
to a different Ruby version' at
'/working/lib/datadog/profiling/load_native_extension.rb:22:in `<top (required)>''

With the fix, the profiler starts up successfully.

[r1viollet]

LGTM
If upstream ruby relies on this, it sounds good to me
Nice reproducing and checking the behaviour !