Increase robustness of geojson parsing by allowing extra properties and null values

[lognaturel]

Closes issues described on forum starting here. The existing code naively assumed that the geojson top level object would have just a type followed by features in that order and with no other properties.

What has been done to verify that this works as intended?

Added tests based on forum reports. Note that the test case provided includes another nested property with name type which was a really good inclusion. One thing to think about in review is whether there are other tricky structures like that which we should test for.

Why is this the best possible solution? Were any other approaches considered?

I briefly considered using an ObjectMapper instead of the parser. But I do think it's better to be able to stream the parsing. I think this is much more robust but it's possible there are still cases I haven't thought of.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

This does change the geojson parsing strategy quite a bit so there's risk. Our test coverage is good, though, so I don't think it's high.

Do we need any specific form for testing your changes? If so, please attach one.

See tests.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

[seadowg]

As well as the inline comments:

• I do feel like the parsing feels a little "too close to the metal" here. Why not use a proper object mapper here?
• The .geojson example files would be a lot easier to read if they were formatted. You can add .geojson as a JSON file type in IntelliJ using File type associations and then auto format the files.

[lognaturel]

Why not use a proper object mapper here?

Streaming means we don't have to have two in-memory representations of the file. These files can get big so it seems worth it. It also better matches the CSV implementation. More on that in the original PR (#655). I'd rather keep this unless we have a really good reason not to.

The .geojson example files would be a lot easier to read if they were formatted.

I like the semantic formatting of those files. But you're right that it's annoying to have files that aren't auto formatted, fixed, thanks.