Revert "accelerator/cuda: Check for cuda devices"

[wenduwan]

This reverts commit ae98e04.

This is a temporary mitigation for #12156

[edgargabriel]

can you confirm that you are indeed not segfaulting if you remove these lines? Basically, if the dso cannot load for whatever reason on some processes, its irrelevant whether you segfault in the init function vs. another cuda function call later

[wenduwan]

Yes. By reverting this change I can reliably pass the test.

wrt segfault, the only trace I got is pointing to cuda, according to dmesg

[79590.726378] cuda00001400006[73833]: segfault at 7f7f60fddb3f ip 00007f7f61fa7407 sp 00007f7f60d23eb0 error 4 in libgcc_s-7-20180712.so.1[7f7f61f99000+15000]
[79590.734804] Code: bb 0c 00 00 00 e9 f2 fe ff ff 40 80 ff 08 75 9d 80 78 01 00 75 97 0f b6 78 02 48 83 c0 02 e9 17 fd ff ff 49 8b 85 98 00 00 00 <80> 38 48 0f 85 67 fe ff ff 48 ba c7 c0 0f 00 00 00 0f 05 48 39 50

[hppritcha]

so what are we going to do about #12055 I thought we decided about a month ago that the accelerator framework was designed to use DSOs for the components

[wenduwan]

@hppritcha This issue is manifested by the DSO build but it does not stop us from doing DSO build.

After reverting this change our CI started passing again(we do DSO build)

So I think you should go ahead with #12055 while we figure out #12156