Runtime: Use async name resolution on Linux

[scalablecory]

We should use getaddrinfo_a on Linux for async name resolution. It supports cancellation as well, bringing us in line with Windows support. See sample code for a usage example.

Note: Today we do async over sync on Linux.

[Dotnet-GitSync-Bot]

I couldn't add an area label to this Issue.

Checkout this page to find out which area owner to ping, or please add exactly one area label to help train me in the future.

[karelz]

up-for-grabs: We just need to add function to our PAL layer. Then call it from the C# code.
Should be fairly straightforward -- the Linux code will be very similar to Windows code.

[gfoidl]

I'd like to give this a try.

[gfoidl]

I have a question regarding the workflow for testing the native parts.

Steps I've done (on linux):

1. building
2. $ cd src/libraries/System.Net.NameResolution/tests/PalTests
3. $ pushd ../../src & dotnet build & popd & dotnet build /t:test
4. verify tests pass
5. make changes in native code

in a second shell:

1. $ cd /src/libraries/Native
2. $ ./build-native.sh debug x64
3. make sure build is OK

When I test then the changes in native code aren't picked up. Even if i delete libSystem.Native.so then the test pass -- I'd expect them to fail without the native counterpart.

How can I ensure the current libSystem.Native.so is used?

Additional info:
.NET Core 5 SDK was installed before a build of the repo was done.
No custom environment variables got set or any of the default variables got overwritten.

[gfoidl]

LD_DEBUG=libs dotnet build /t:test 2>&1 > /dev/null | grep System.Native

outputs

       678: calling init: /home/runtime/.dotnet/shared/Microsoft.NETCore.App/5.0.0-preview.3.20169.1/libSystem.Native.so
       701: calling init: /home/runtime/.dotnet/shared/Microsoft.NETCore.App/5.0.0-preview.3.20169.1/libSystem.Native.so
       701: calling fini: /home/runtime/.dotnet/shared/Microsoft.NETCore.App/5.0.0-preview.3.20169.1/libSystem.Native.so [0]
       678: calling fini: /home/runtime/.dotnet/shared/Microsoft.NETCore.App/5.0.0-preview.3.20169.1/libSystem.Native.so [0]

so the native-libs get loaded from the shared installations (from the build) and not from the artifacts-location.

With some hacks* this could be solved, but is there a "nice way" to use the currently built native libraries in the managed tests?

* even LD_PRELOAD doesn't do the job

[stephentoub]

I agree it'd be nice if there were a better solution (and there may be... @ViktorHofer?), but I always just copy the built binaries into the testhost shared folder after building them.