Add `CsvParser.Feature.EMPTY_STRING_AS_NULL` to allow coercing empty Strings into `null` values

[cowtowncoder]

(from FasterXML/jackson-dataformat-csv#146 by @robmoore)

We're working with a set of files that contains both empty strings and NULL values. We are using .withNullValue("NULL") as well as DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but are ending up with empty strings rather than null values for these cases.

In issue 112, @cowtowncoder suggested it might be possible to support an alternate notation in addition to the explicit null value indicated in withNullValue().

[tyler2cr]

@cowtowncoder I'm interested in contributing to this if it's still a viable enhancement

[cowtowncoder]

@tyler2cr yes I think this would be great thing to have. Could make it into 2.10.0, too.

[tyler2cr]

Ok - is the approach to ensure that the ACCEPT_EMPTY_STRING_AS_NULL_OBJECT is applied to Strings when MapperFeature#ALLOW_COERCION_OF_SCALARS is enabled?

FasterXML/jackson-dataformat-csv#112 (comment)

[cowtowncoder]

Good question. Javadocs say (at least for 2.10, it was clarified at some point):

NOTE: this does NOT apply to scalar values such as booleans and numbers ...

which means Strings, too. However... since CSV only really has scalar properties, it could be special case.
Specific discrepancy here is actually this: DeserializationFeatures are designed to work above streaming layer, after parser has indicated token type. But what we do here is to change behavior of parser, to expose empty String as null token, not String token.

Given this, I think what makes more sense is to actually define a new CsvParser.Feature, enabling of which would expose empty CSV values as nulls; and then affect all Java types.

[tyler2cr]

@cowtowncoder I submitted a pull request that’s ready for code review.

[cowtowncoder]

Thanks!