Fix default value initialization for nullable properties

[habbes]

Problem

Fix #342

When a property definition in the CSDL document specifies a default value like follows:

<Property Name="Date" Type="Edm.Date" Nullable="false" DefaultValue="2020-02-02" />

The generated code (for both C# and VB) includes a corresponding initialization for the backing value of the CLR property:

private global::Microsoft.OData.Edm.Date _Date = global::Microsoft.OData.Edm.Date.Parse("2020-02-02");

However, when the CSDL property is nullable, the initializer is not properly generated:

<Property Name="Date" Type="Edm.Date" DefaultValue="2020-02-02" />

private global::System.Nullable<global::Microsoft.OData.Edm.Date> _NullableDateProp = 2020 - 02 - 02;

Depending on the property type and initialization, this may lead to errors. For example, the above expression will evaluate to an integer instead of a date, causing a compile-time error.

Solution

The code generator generates different initialization code based on the data type. However, its data-type detection logic does not take into Nullable types into account. A boolean EDM property with Nullable set to true will be translated to Nullable<bool> in .NET instead of bool. This PR makes adjustments to this logic such that Nullable<T> and T are treated the same way for the purpose of property value initialization. I added a StripNullableFromTypeName helper method for both VB and C# and use it to transform Nullable<T> into T so that the property initializer can detect the underlying type correctly and generate the correct initialization code.

[ElizabethOkerio]

so the type name here will be in form of a string? Exa Nullable<DateTime> then the method returns DateTime but in string form?

[ElizabethOkerio]

Maybe I do not understand but why can't we check if a type is nullable without the conversions to string?

[habbes]

Because by the time we get to use this method, the input type name is already in string form. I do agree that it would be more robust to use actual reflection type metadata to detect nullability, but we don't have that information in the method where this method is used. To use types would require refactoring a lot more methods and a lot more work than what I "budgeted" to fix this bug.

[KenitoInc]

LGTM