SavedObjects aggregation: add validation / path rewriting for sort parameter

[pgayvallet]

Initial discussion: https://github.com/elastic/kibana/pull/114585/files#r729414544

We're not currently validating and rewriting attribute paths used inside the sort parameter (used in multiple aggregation types, even if top_hits is the only one supported in the subset we've implemented for SOs at the moment)

This means consumers currently have to use

aggs: {
    myAggr: {
        top_hits: {
            sort: [
                { [`${myType}.someAttribute`]: { ... } }
            ],
        },
    },
}

instead of

aggs: {
    myAggr: {
        top_hits: {
            sort: [
                { [`${myType}.attributes.someAttribute`]: { ... } }
            ],
        },
    },
}

Which is inconsistent with the rest of the API, in addition to skipping all the validation/rewrite we want to perform when attribute paths are used in aggregations (even if I don't think there is any security concerns here, given what sort does)

However, this validation is more complex than all we're currently supporting, due to the possible shapes of the sort option:

1. This can either be a sort value or an array of sort value
2. Each value can have different shapes, either records or plain strings.

E.g

// one field, short syntax 
{ 
   sort: 'my-field', 
}

// multiple fields, short syntax
{ 
   sort: ['my-field', 'my-other-field'], 
}

// one field, long syntax
{ 
   sort: { 
      'my-field' : { order: 'asc' } 
   } 
}

// multiple fields, long syntax
{ 
   sort:  { 
        'my-field' : { order: 'asc' },
        'my-other-field' : { order: 'asc' }
    }, 
}

// multiple fields, long syntax using one object per field (yea, this is supported)
{ 
   sort: [
      { 'my-field' : { order: 'asc' } },
      { 'my-other-field' : { order: 'asc' } },
   ], 
}

See the sortSchema for more info about the shape of this option:

kibana/src/core/server/saved_objects/service/lib/aggregations/aggs_types/common_schemas.ts

Lines 12 to 29 in 7f6d7b3

	const fieldSchema = s.string();
	export const sortOrderSchema = s.oneOf([s.literal('asc'), s.literal('desc'), s.literal('_doc')]);
	const sortModeSchema = s.oneOf([
	s.literal('min'),
	s.literal('max'),
	s.literal('sum'),
	s.literal('avg'),
	s.literal('median'),
	]);
	const fieldSortSchema = s.object({
	missing: s.maybe(s.oneOf([s.string(), s.number(), s.boolean()])),
	mode: s.maybe(sortModeSchema),
	order: s.maybe(sortOrderSchema),
	// nested and unmapped_type not implemented yet
	});
	const sortContainerSchema = s.recordOf(s.string(), s.oneOf([sortOrderSchema, fieldSortSchema]));
	const sortCombinationsSchema = s.oneOf([fieldSchema, sortContainerSchema]);
	export const sortSchema = s.oneOf([sortCombinationsSchema, s.arrayOf(sortCombinationsSchema)]);

Until now, we're succeeded in using a naive hardcoded list of the attributes we needed to rewrite the key or the value for. But until now, we never encountered a situation where the validation and rewrite was depending on the shape of a polymorphic value. I'm not sure the current approach will work for this specific case, and I'm afraid we may have to rethink the validation (or to introduce specific code for this sort exception)

As a sidenote: we're not handling arrays in aggregation structure at all atm. It currently only work because the Object.entries call in

kibana/src/core/server/saved_objects/service/lib/aggregations/validation.ts

Lines 173 to 176 in d920682

	const recursiveRewrite = (
	currentLevel: Record<string, any>,
	context: ValidationContext,
	parents: string[]

'reconstruct' an object with the array's indices as keys.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[spong]

As referenced in the description, there is one usage in SecuritySolution that'll be affected by this fix if still around (usage is deprecated and may be removed in early 8.x). Corresponding find_statues/find_rules FTR/integration tests will start failing once fixed as well.