Fixed DataFilters to show all filter options

[halocline]

What does this PR do?

Closes #6940.

Uses unfilteredData instead of data as source to build up default filter options. Previously, the logic was built up from data, however if data reached a length of zero, then no object was available to build up the options.

Where should the reviewer start?

• review issue
• DataFilters.js

What testing has been done on this PR?

• Storybook
• Added unit tests

How should this be manually tested?

Use the following stories:

• https://storybook.grommet.io/?path=/story/data-data-simple--simple
• Story 1 - when properties is not specified, data provides default filters.
• Story 2 - when properties is specified, properties becomes the schema definition for which properties are filterable by filters.

For each:

1. Use a combination of filters to get zero results.
2. Re-open filters, all filter properties should be options.

Story w/out properties prop:

 <Data
    data={[
      {
        name: 'aa',
        enabled: true,
        rating: 2.3,
        sub: { note: 'ZZ' },
        tags: ['qa', 'staging', 'prod'],
      },
      {
        name: 'bb',
        enabled: false,
        rating: 4.3,
        sub: { note: 'YY' },
        tags: ['qa', 'staging'],
      },
      { name: 'cc', sub: {}, tags: ['qa'] },
      { name: 'dd' },
    ]}
    toolbar
  >
    <DataTable
      columns={[
        { property: 'name', header: 'Name' },
        { property: 'sub.note', header: 'Note' },
        {
          property: 'tags',
          header: 'Tags',
          render: ({ tags }) => (tags ? tags.join(', ') : null),
        },
      ]}
    />
  </Data>

Story with properties prop:

 <Data
    data={[
      {
        name: 'aa',
        enabled: true,
        rating: 2.3,
        sub: { note: 'ZZ' },
        tags: ['qa', 'staging', 'prod'],
      },
      {
        name: 'bb',
        enabled: false,
        rating: 4.3,
        sub: { note: 'YY' },
        tags: ['qa', 'staging'],
      },
      { name: 'cc', sub: {}, tags: ['qa'] },
      { name: 'dd' },
    ]}
    toolbar
    properties={{
      name: { label: 'Name' },
      'sub.note': { label: 'Note' },
      tags: {
        label: 'Tags',
        options: [
          { label: '01 - Development', value: 'dev' },
          { label: '02 - QA', value: 'qa' },
          { label: '03 - Staging', value: 'staging' },
          { label: '04 - Production', value: 'prod' },
        ],
      },
    }}
  >
    <DataTable
      columns={[
        { property: 'name', header: 'Name' },
        { property: 'sub.note', header: 'Note' },
        {
          property: 'tags',
          header: 'Tags',
          render: ({ tags }) => (tags ? tags.join(', ') : null),
        },
      ]}
    />
  </Data>

Do Jest tests follow these best practices?

• screen is used for querying.
• The correct query is used. (Refer to this list of queries)
• userEvent is used in place of fireEvent.
• asFragment() is used for snapshot testing.

Any background context you want to provide?

What are the relevant issues?

#6940

Screenshots (if appropriate)

Do the grommet docs need to be updated?

No.

Should this PR be mentioned in the release notes?

Yes.

Is this change backwards compatible or is it a breaking change?

Backwards compatible.

[halocline]

Is it reasonable for us to only be looking at the first object to build up the default options? This assumes the first object is representative of all objects in the data set and has all properties. What if other objects have properties not represented?

[MikeKingdom]

I think it's reasonable given they can specify properties if they have sparse objects for some reason

[MikeKingdom]

I think it's reasonable given they can specify properties if they have sparse objects for some reason

[jcfilben]

Looks good!