`export` should have its own schema

[SteveL-MSFT]

Summary of the new feature / enhancement

export takes an instance of the object schema, but the schema for export is used as a filter, so this means export can take wildcards, ranges, etc... that may not be appropriate for get, set, test.

This also becomes a problem when key properties are supported, but not required for export

Proposed technical implementation details (optional)

In the resource manifest under the export section, have a new schema property. If it doesn't exist the engine continues to use the top level schema.

[michaeltlombardi]

Worth considering whether the export.schema field must be fully separately defined from schema or whether it should function as an override (by merging export.schema over schema).

If it requires fully separate definition, that requires some duplication, as the $defs can't be shared between the fields.

An alternative option is to efine a custom keyword, like x-dsc-export, which schema authors can use to provide the alternate schema for export operations in the general resource instance schema. The keyword could be defined at the top-level to override the full schema, or in property subschemas to override that property on export (we should only support either top-level or per-property, but not both).

[SteveL-MSFT]

WG discussed this, we'll use the apt python resource to test both approaches

[SteveL-MSFT]

WG discussed this further, current proposal:

In the resource manifest, have a schema property under the export section. If the resource export does not accept filtering at all, then schema should be set to false explicitly, otherwise if no schema under export, dsc will continue to use the single schema defined for everything for validation.

In the PowerShell resource code, have a separate class defined but accepted as the arg type for export optional parameter:

[DscResource()]
MyResource {
  static Export([FindMePlz]$filter) {}
  static Export() {}
}

class FindMePlz {}