Add Tags to `RecordsWrite`

[LiranCohen]

Allowing a user to tag a record, and then query for records that match the tags.

export type Tags = {
  [tag: string]: Array<string | number | boolean>
};


export type RecordsWriteDescriptor = {
  interface: DwnInterfaceName.Records;
  method: DwnMethodName.Write;
  // ...
  tags: Tags;
};

Write:

{
  "schema": "https://schema",
  "protocol": "https://protocol",
  "protocolPath": "some/path",
  "tags": {
    "tag1": ["val1", "val2", "val3"],
    "tag2": [123, 456],
    "tag3": [true]
  }
}

Query:

{
  "filter": {
    "schema": "https://schema",
    "tags": {
       "tag1": "val2",
    }
  }
}

[csuwildcat]

What about starting out with the Phase 1 structure/behavior below, then at some later date we can add top-level array passage of multiple objects to enable ORs later:

// Phase 1:

{
  tags: { // if tags is an object, its full set of keys and values are evaluated as exact match
    tag1 ["val1", "val2"], // Must have 'tag1' with both 'val1' and 'val2'
    tag2: [123] // Must also have 'tag2' and a value '123'
  }
}

// Phase 2:

{
  tags: [ // allow tags to be an array, and if it's an array, each member is an OR
    { // every object's full set of keys and values is evaluated as exact match
      tag1 ["val1", "val2"], // Must have 'tag1' with both 'val1' and 'val2'
      tag2: [123] // Must also have 'tag2' value '123'
    },
    { // if the first matching object misses, this second object would be tried
      tag3: [true] // Must have 'tag3' and be 'true'
    }
  ]
}

[csuwildcat]

What I liked about the proposal above is that 1) the matcher objects retain the same behavior, 2) the only future change is to make tags polymorphic but bound to OR, and 3) at no point do we introduce any DSL strings, the whole thing remains an object literal syntax that seems rather intuitive if you know that a top-level array = OR and value arrays = AND.

[LiranCohen]

@csuwildcat interesting with the array of tag objects like that for the queries to represent both AND and OR.

Our current typing/representation of filters (although not being used) would read the array as an OR, have to think about what that looks like in the implementation.

Worst case scenario to get this feature in sooner rather than later would you be opposed to your Phase 1 + 2 being the Phase 2 and Phase 1 being a single match?

[csuwildcat]

Single match is fine, I suppose we can always make that polymorphic too, given the behavior is rather simple. That would be effectively 3 simple things to remember about the structure to account for the vast majority of queries (literally every one I could think of outside of inner-string comparisons, which is a whole different beast I don't want to touch).

[thehenrytsai]

My Phase 1 is sooo puny compared to all yours:

"tags": {
    "tag1": ["val1", "val2", "val3"]; // one and only property, { } container is only there for extensibility purposes in phase 50
  }