Skip async variants in MemberLoader::FindMethod (blocking wasm)

[jkotas]

This PR breaks browser/interp probably until we remove the temporary signature detection

To unblock us, we will turn asyncv2 for browser off in #122495
That PR also brings first CI smoke test for CoreCLR/WASM😅

Originally posted by @pavelsavara in #121732 (comment)

[dotnet-policy-service]

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

[jkotas]

The temporary signature detection should work just fine with RuntimeAsync=1. I think this suggests that there is a bug exposed by setting RuntimeAsync=1. Wasm just got unlucky to hit this bug first. We are likely going to see the underlying bug on other architectures in different scenarios.

[jkotas]

cc @VSadov @agocke

[pavelsavara]

In debugger I saw

and the nReturnType was ELEMENT_TYPE_VOID

runtime/src/coreclr/vm/assembly.cpp

Line 1155 in ac7db14

if ((nReturnType != ELEMENT_TYPE_VOID) && (nReturnType != ELEMENT_TYPE_I4) && (nReturnType != ELEMENT_TYPE_U4))

[jkotas]

Looks like a bug in MemberLoader::FindMethods or MethodTable::MethodIterator. @VSadov Should we skip async variants there?

Also, do we still need to the insert the modreqs into the async variant signatures? https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/methodtablebuilder.cpp#L3422-L3440 . It looks like a left over from the prototype.

[VSadov]

do we still need to the insert the modreqs into the async variant signatures?

We used to require modreqs in async signatures because:

1. In the original prototype async signatures were first class.
   I.E. Roslyn would know the meaning and could reason about the modreqs and would generate methods with modreqs as needed. That is no longer the case.

2. VM/JIT could figure if something is async or not by looking at the signature. I am not sure if that is true anymore either.

I think the main reason now is just disambiguation of variants.

As an example:

A class may have:
virtual T FooBar()
virtual Task<T> FooBar()
virtual ValueTask<T> FooBar()

I am afraid when a derived class overrides all these, without disambiguation we might have a mess or at least some extra complexity in resolving what overrides what.
I am fuzzy on whether call convention is a part of overrides/implements or similar lookups. If call convention is a part in every kind of lookups that we care about, then modreq`ing the async signatures is redundant.

Another, less important, reason is that it is somewhat useful when debugging. We often lose the name/desc of methods, but we tend to keep around signatures. When you see these modreqs in a signature, you immediately know a lot more about what is going on. This part we can live without, it is just convenience.

For the most part, even if redundant, the modreqs were very cheap to keep having and even if the purpose is just use in debugging/dumping, they were not a big burden to have.

--
I did not look yet at what is the problem with wasm and MemberLoader::FindMethod. Just commenting on why we still have modreqs.