ISSUE DESCRIPTION

This issue will cause 2dsphere indexes created after SERVER-84794 but before SERVER-116179 (this patch) to cause validation failures and warnings. In certain queries and document structures where a legacy point appears before a geoJSON point in field order AND the point values differ, it may also result in incorrect query results, due to changes in how indexes get parsed.

In SERVER-84794, 2dsphere index parsing was changed to always prefer parsing GeoJSON points, regardless if a legacy point exists in the document or not. This means that documents that have both formats present, but in different values, will generate new 2dsphere index keys and lead to $match queries not matching the correct set of documents. See the description in SERVER-84794 for a more thorough explanation. However, this change was not gated by a bump to 2dsphere index version (which was on v3).

SERVER-116179 adds the old indexing behavior back and reintroduces the SERVER-84794 logic as a v4 index. 

DIAGNOSIS AND IMPACT

The validation errors caused by SERVER-116179 will manifest similarly to AF-15974, with errors reported similar to:

• index/error geometry.features.geometry_2dsphere: Index 'geometry.features.geometry_2dsphere' was created with 2dsphereIndexVersion 3, but validation indicates it should be rebuilt with version 4. Please drop and recreate this index with version 4.

In addition, queries on 2dsphere indexes created between the patch for SERVER-84794 and SERVER-116179 (which should only affect users using v8.2) may result in the wrong sets of documents being returned for match queries.

REMEDIATION AND WORKAROUNDS

The remediation for this issue is to recreate the 2dsphere index. Users should default to using the v4 behavior, as it is the most up-to-date, however, users can specify a `2dsphereIndexVersion: 3` and recreate a v3 index correctly as well.{}