expose an optional preserve_order feature that passes through to serde_json

[michaelkirk]

By default, serde_json uses a BTreeMap to store JSValue's, which means that properties can get unexpectedly re-ordered. serde_json has an optional (disabled by default) preserve_order feature for users who want fields to preserve the order in which they were inserted.

Most of the time reordering is fine, and it's faster, so probably we should maintain the default behavior.

The issue I'm facing right now is while working on geozero, when converting formats back and fourth, we have a notion of field order which is respected for some formats, but not geojson. It'd be convenient to be able to enforce field ordering in geojson for those who want it.

Another small thing, even though JSON equality is order agnostic, I think there is an expected ordering of fields in a geojson for readability, like this:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [125.6, 10.1]
  },
  "properties": {
    "name": "Dinagat Islands"
  }
}

Not:

{
  "properties": {
    "name": "Dinagat Islands"
  }
  "geometry": {
    "coordinates": [125.6, 10.1]
    "type": "Point",
  },
  "type": "Feature",
}

Adding the feature to Cargo.toml is pretty easy, but it breaks a lot of tests with hard-coded expectations around property order:

Left:  {"type":"Feature","geometry":{"type":"Point","coordinates":[1.1,2.1]},"properties":{}}
Right: {"geometry":{"coordinates":[1.1,2.1],"type":"Point"},"properties":{},"type":"Feature"}

We could change all these to be checks for structural equality, rather than exact string matching, but I wanted to check in before I spend the hour or so doing that, since there are a dozen or so broken tests.

[urschrei]

field order which is respected for some formats

Huh, TIL. I think it's def a useful optional feature.