Creating correct model state keys when body model binding for missing properties or body. Also adds integration tests

[harshgMSFT]

The model state keys for body bound models which are bound at property will use the entire model name with this change for example
Consider

        public class Person
        {
            [FromBody]
            public Address Address { get; set; }
        }

        public class Address
        {
            [Required]
            public string Street { get; set; }

            public int Zip { get; set; }
        }

Request body { "Zip" : 12345 }
In this case the error key would be "prefix.Address.Street" (assuming there is a prefix because of additional metadata/positioning for/of the Person model).

public class Person
{
       [Required]
       public string Name { get; set; }
}

public void Action([FromBody]Person p)
{
}

Request body { }
In this case the prefix gets ignored and the error key is Name.
Please note this is so that we are compatible with MVC 5.0

public class Person
{
       [Required]
       public string Name { get; set; }
}

public void Action([FromBody][ModelBinder(Name = "prefix")] Person p)
{
}

public void Action2([FromBody][Bind(Name = "prefix")] Person p)
{
}

Request body { }
In both these cases (Action and Action2) the prefix gets ignored and the error key is Name.
This is a slight improvement from mvc, as in MVC the action parameter would be null.

The followup for this would be to fix #2416 -
This PR ignores the validation assuming that #2416 will address the issues and update the test.

NOTE: previous versions of mvc did not have property binding and hence there is no precedence in this case. For MVC and Web API it was possible to body bind an action parameter which used an empty prefix instead of a parameter name for adding errors to model state (In case of MVC if a custom prefix was provided, it failed binding from body i.e the parameter was null).

[harshgMSFT]

not sure why this shows up.

[dougbu]

this is fine. just means it is a test project. check it in separately, together w/ the rest of this PR, or whatever...

[rynowak]

In general just let VS do what it's going to do.

[dougbu]

@harshgMSFT it isn't clear what the expected behaviour is in any of the cases you've outlined or why the current behaviour is incorrect. please describe the exact Asp.Net 4 and MVC 5 behaviours for these cases.

separately what reported issues (if any) will this PR fix?

[dougbu]

name of class and containing file must match

[harshgMSFT]

Will fix.

[harshgMSFT]

@dougbu I have updated the comment to provide a better description. And no there is no issue for this one.

[rynowak]

This is a good refactor. I had scoped out something similar thinking about building these tests.

[harshgMSFT]

@dougbu @rynowak updated with the behaviors agreed on.

[rynowak]

Didn't we conclude in another discussion that this kind of logic is incorrect, and we can only really know this by adding it back to the context?

[harshgMSFT]

Yes, however that is a corner scenario and we should address this when we address that issue.

[harshgMSFT]

#2425

[rynowak]

[dougbu]

this class has a <summary/> but no member-level doc comments. prefer if you add comments for new public method but at least open a "task" issue to do the necessary.

[harshgMSFT]

Will add doc comments for the public api surface for this class in a separate pr ( not holding this one for furhter review (as you have already signed off)). Not opening individual issues for adding doc comments, there are tons of places which needs fixing and this could be tracked by a singular issue.

[dougbu]

with the perfect doc comment addition 😸