EES-5740 Backend work for filter hierarchies

[mmyoungman]

This PR implements the backend work needed to create filter hierarchies on the table tool page.

Filter hierarchies are saved in a new column on the Files table. This will soon be moved to the new DataSetFileVersion table when that is created.

It's possible we may want to not merge this until some of the frontend work has been done for this - it's possible the frontend might want the data in a different format and/or more information (like FilterItem labels, for example).

I've added three new test data sets for testing filter hierarchies.

A sole filter hierarchy stores data about all the "tiers" in that hierarchy. Tiers are specified in the meta.csv file of the data set by referring to a parent filter via the filter_grouping_column column. Tiers consist of a parent filter and child filter, and list which child filter items exist under which parent filter items. There is no error checking on this as we assume this will be done by the data screener and if bad data did get imported it could simply be removed by removing the data set.

Each tier stores the root filter, the child filter, the root filter options (or items) and a Dictionary of root filter items and child filter items.

We could remove RootOptionsIds from DataSetFileFilterHierarchy, but I think we may want to add extra info to these filter items like label their label, so I'm leaving it for now. We're not expecting to use this in prod for a while. I also suspect the format of the response the backend will change once the frontend work gets done, but rather than leaving this PR blocked until then, we're just merging it now.

It's possible for a data set to have more than one filter hierarchy, if there is more than one root filter in the data set. This is why we return a list of hierarchies. If there were multiple hierarchies attached to a data set, the frontend would display these separately lists of tiers.

There is no migration as no existing data set will have a filter hierarchies.

See the related Jira ticket for discussion / justification for why this as been implemented as it has.

[tomjonesdev]

Don't think you need to set an initial value of null on a nullable property. Also, since the other properties are auto-instantiated, you should be ok to add #nullable enable to this class without raising any warnings/changing anything else.

[mmyoungman]

I've removed the = null;

There is no need to add #nullable enable already set project wide in the csproj file.

[tomjonesdev]

Just a minor point, but I don't think the purpose of this loop is particularly clear, especially since the logic which follows is quite complex. Perhaps it would help scanning/readability if you defined a named condition, and updated it per iteration as needed? Wouldn't need the comment then either, e.g.

var hasChildFilter = true;
while (hasChildFilter)
{
    ...
    hasChildFilter = false;
}

[mmyoungman]

This was actually how I originally had it (pretty much) but changed it thinking this would make it easier to follow the logic at the end of each loop iteration setting up the next.

I'll have a think about how this can be done - cause we've thought there is a slight issue here so probably worth it.

[mmyoungman]

I gave this some thought and decided to leave it in the end. I don't think there is a big advantage to shifting this around so better to save the time and just get it in.

The logic already takes a bit of time to wrap your head around, so this seems relatively minor in comparison.