Consider removing nulls from EntityProperty/DynamicTableEntity

[davidmatson]

EntityProperty currently supports values containing nulls, and for any property "foo" DynamicTableEntity supports both:

1. Adding a property named "foo" with a null value.
2. Not adding a property named "foo" at all.

But both of those options are treated identically by the Table Service REST API, as documented here (search for "null" on each page):

• https://docs.microsoft.com/en-us/rest/api/storageservices/update-entity2
• https://docs.microsoft.com/en-us/rest/api/storageservices/merge-entity
• https://docs.microsoft.com/en-us/rest/api/storageservices/insert-or-replace-entity
• https://docs.microsoft.com/en-us/rest/api/storageservices/insert-or-merge-entity

Because null values are treated as missing values by the storage service, they're never returned when querying entities (a null value will never be read back).

Given the shape of EntityProperty/DynamicTableEntity, I was about to write a bunch of code to handle reading/writing null values as distinct from a missing property value. I happened to test the storage service REST API to understand the distinction and thankfully discovered there is no difference, but the EntityProperty/DynamicTableEntity API was misleading in this regard. Having just one way to say a property doesn't have a value (it isn't in the dictionary) would simplify and clarify the .NET API here.

(Note that I'm not suggesting any changes to TableEntity - I agree it's useful to support int? and bool? properties there - this comment is only about the EntityProperty/DynamicTableEntity layer.)

(Copied from Azure/azure-storage-net#550.)

[sakash279]

This is a storage service behavior to not distinguish values if they are null or don't have a value. At this point, given this would be a breaking change, we're not considering to remove this behavior in EntityProperty/DynamicTableEntity in the .NET sdk.