NameResolutionPal.Unix: fixed loss of address family information in async lookup

[gfoidl]

Fixes #47103

C's designated struct initializer worked at the time it was suggested as for ar_request a static const value was used.
Then address family handling got added to master and while resolving the merge conflict and refactoring a bit of code the static const value was gone, and while (recursively) initializing the struct state the hint-field got lost (overwritten)*, and so the address family information that is used in the (native) callback of the async lookup.

This PR changes the initialization of the state-struct, so that the information isn't lost.

I've also removed some dead code, that was an artefact of refactoring and it's removal got lost during all the changes in #34633.

I'm wondering why the outerloop-test in my linux-vm didn't fail back then...

* quoting the docs:

Omitted fields are implicitly initialized the same as for objects that have static storage duration.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #47103

C's designated struct initializer worked at the time it was suggested as for ar_request a static const value was used.
Then address family handling got added to master and while resolving the merge conflict and refactoring a bit of code the static const value was gone, and while (recursively) initializing the struct state the hint-field got lost (overwritten)*, and so the address family information that is used in the (native) callback of the async lookup.

This PR changes the initialization of the state-struct, so that the information isn't lost.

I've also removed some dead code, that was an artefact of refactoring and it's removal got lost during all the changes in #34633.

I'm wondering why the outerloop-test in my linux-vm didn't fail back then...

* quoting the docs:

Omitted fields are implicitly initialized the same as for objects that have static storage duration.

Author:	gfoidl
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[wfurt]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[stephentoub]

What makes this dead?

[wfurt]

It seems like the TrySetAddressFamily() bellow does it inside so it seems like duplication to me.

[stephentoub]

Ah, not that it's dead code but that it's unnecessary because the same check is performed immediately after. Ok.

[gfoidl]

Now

runtime/src/libraries/Native/Unix/System.Native/pal_networking.c

Line 617 in 311de30

if (!TrySetAddressFamily(addressFamily, &state->hint))

sets the address family (after the code for sync and async got unified).

The removed code is a left-over from before that unification. The platformFamily isn't used anymore, so it's "dead".
This was forgotten in the other PR (due the work in single file host build).

(For completeness...late reply due being in different timezone 😉).

[wfurt]

LGTM.
It seems like all the outerloop failures are not related e.g. I did no see any name resolution related failure.