Take the field index, not name, in the feature getters and setters

[lnicola]

• I agree to follow the project's code of conduct.
• I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

---

Field access by name tends to be very slow (I've seen it take 30% of the time in some programs), but beginners are unlikely to realize that they're doing a number of expensive lookups per feature.

Summary of changes:

• drop field getters that take a field name
• change the field setters to take an index instead of a name (the index versions were missing)
• make field_count return usize for consistency
• add Defn::field_index and make Feature::field_index public
• drop LayerAccess::create_feature_fields (it could be updated, but it's a bit weird)

[lnicola]

r? @metasim, @ChristianBeilschmidt, @jdroenner since this is a relatively big change
r? @latot since you said you wanted to get involved

Hopefully I'll be able to get rid of this thing soon:

(it goes on and on)

[metasim]

To consider: Some of these retrieval functions return Result<Option<T>>. Should that convention be used here? I'm on the fence. It arguably adds more friction but is more precise. At the other end of the spectrum is just Option<usize>, which has nicer ergonomics, but basically swallows FFI-related errors.

[lnicola]

The Option there is meant for null (or unset, but I'm not sure how well we support those) fields. For the getters, I think the "simple" ones are infallible and return some kind of 0 for invalid indexes, while the ones returning lists are fallible.

So Result<Option<T>> sounds right for the getters and setters. field_index could return Option<usize>, but that's less nice to use (because it won't mix with Result and ?), and it does swallow the FFI errors.

[latot]

I think this is nice, some questions... can we actually change the fields in any way that could broke the field id?

From where is the image? I can see some transformations from isize to i32 with as.

[lnicola]

can we actually change the fields in any way that could broke the field id?

You can delete fields from the Defn of a layer, but it won't reflect in the fields of the features, and I don't think we even expose that.

From where is the image? I can see some transformations from isize to i32 with as.

From usize, maybe, but most of those are checked (I think layer iteration is the exception). GDAL fields are 32-bit and positive (-1 means a missing field), but Rust uses probably expect usize. We do a similar thing for raster dimensions. But it's a small change and can be reverted easily (either now or in the future).

Or we could go the other way around and introduce a FieldIdx type that wraps an i32.