Ensure IFormFile binding related scenarios are in good shape in 3.0

[mkArtakMSFT]

We've seen multiple model-binding issues specifically around IFormFile type and we need to make sure we handle it in a generic way.

[mkArtakMSFT]

We need to make sure this works in 3.0 and we will handle porting 3.0 changes to 2.2 later.

[pranavkm]

In general things look better compared to 2.2. We do not have recursions and sub-graphs of objects without any models do not get bound e.g. scenarios like - #9321 - work as expected. Collections of form files also work well.

There is an issue where IFormFile objects that are deeply nested may not get correctly bound. Consider this:

public class Root
{
   public Sub1 Sub1 { get; set; }
}

public class Sub1
{
    public int Id { get; set; }
   
    public Sub2 Sub2 { get; set; }
}

public class Sub2
{
   public IFormFile File { get; set; }
}

Root.Sub1.Sub2.File only gets bound if Root.Sub1.Id has a value. The recursion in model binding decides to bail when it finds that neither Id nor Sub2 have any values in value providers.

A source of the problem is that model binders are unaware of the list of files being sent. One way to address this would be to make them aware of this. (think a ValueProvider that only responds to ContainsPrefix based on posted file list). Users may be able to workaround this simply by generating a hidden field with the name of the form file. I haven't tried out all the cases with this to confidently say this works consistently.

Much of the change we did here to address IFormFile related issues is within the ComplexTypeModelBinder. There's a good chance we could port a change and put it behind a compat (AppContext) switch that's off by default. Users may have the choice to enable it in their startup code.

[rynowak]

think a ValueProvider that only responds to ContainsPrefix based on posted file list

This was one of the ideas we had a looooong time ago to try and make files work good. It's not clear to me why anything about this value provider needs to be special. It makes sense that we'd put this value provider last and make it just return an empty value.

Moreover, I don't recall why we didn't do this.