Fix reflection to work with default interface methods

[MichalStrehovsky]

Fixes #15645.
Fixes #15644.

[MichalStrehovsky]

@atsushikan Could you have a look please?

Cc @sergiy-k

[ghost]

I know this is preexisting but the "continue" should be on its own line.

[ghost]

Other than that, LGTM

[MichalStrehovsky]

I moved this check up to align with how this is done for the else (not interface) case below.

[MichalStrehovsky]

@atsushikan I had to also add what I had to do to fix reflection invoke because I didn't realize this hits that code path with the assert (I worked on several things in parallel in my local branch and Invoke didn't have tests ready yet...)

[ghost]

You could now use the cached value for methodAttributes.

[MichalStrehovsky]

Yeah, but I would also have to update the "not an interface" case below to do the same to stay consistent. I'm not convinced it's worth the noise in git blame.

[ghost]

LGTM. Is there anything that needs to happen on the Invoke path on Project N?

[MichalStrehovsky]

LGTM. Is there anything that needs to happen on the Invoke path on Project N?

I'll open that particular can of worms later.

Btw: do you know of any other parts of the CLR reflection stack that would need updating?

[ghost]

Reflection doesn't even expose method .overrides today so these things are going to be largely invisible to the apis that walk up base class chains to generate lists of methods. (Assuming interface defaults work the same way as other .overrides- i.e. you have to invoke them through the interface-typed this, not a class-based this)

So I imagine any update, if any, will come in the form of requests to add or change the behavior of apis - not so much bug fixes. Or at least documentation that anticipates user confusion (why does GetMethod() on a class find inherited members but not GetMethod on an interface.)