Add Point reading from coordinate arrays

[DragonFSKY]

Closes #4997

This PR adds a reading converter that maps coordinate arrays such as [-73.99171, 40.738868] to Point.

The existing document-based Point mapping remains unchanged. Tests cover the direct converter and the MappingMongoConverter path for a domain Point property.

Tests:

• ./mvnw -s settings.xml -pl spring-data-mongodb clean test '-Dtest=GeoConvertersUnitTests,MappingMongoConverterUnitTests#shouldReadEntityWithGeoPointFromArrayCoordinates+convertsListToBasicDBListAndRetainsTypeInformationForComplexObjects+convertsListToBasicDBListWithoutTypeInformationForSimpleTypes'

Checklist:

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Do not submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[christophstrobl]

Thank you @DragonFSKY for providing the PR. Since we already released an RC for the current release train we might consider your contribution for the next iteration.

Until we have time to do a full review of the proposed changes I'd like to leave a comment already that I think needs to be addressed.

Currently it is not possible to auto convert coordinates : [x,y] into a Point coordinates field.
The proposed changes fix this, but would also, when saving back the entity, silently change the stored document to coordinates : { x: ..., y: ...}.

I could think of something like the following (which is currently not supported right now) to prevent this from happening.

@Field(targetType = FieldType.ARRAY)
Point coordinates;

Please, the above is just from a quick glance and should not be taken as implementation advice. Let's discuss things before spending more time changing the PR.

[DragonFSKY]

Sorry, my initial thinking was incomplete here. I focused on the read side first and did not think through the read/write storage shape carefully enough.

Looking at the current upstream mapping code, Point is still written through the existing { x, y } representation. So if array coordinates are accepted as Point on read, the storage shape probably needs to be considered explicitly as well; otherwise a later write could store a different representation.

My current thought is that array-backed Point mapping might need to be opt-in, for example:

class Location {

    @Field(targetType = FieldType.ARRAY)
    Point coordinates;
}

This way, an explicitly array-backed property could preserve the array representation:

{ "coordinates": [ -73.99171, 40.738868 ] }

while existing Point mappings without the annotation would keep using the current default representation:

{ "coordinates": { "x": -73.99171, "y": 40.738868 } }

Does that sound like a reasonable direction? If you see a better approach, please feel free to point me in that direction.