Investigate use of TopPage for elemental sitetree search

[emteknetnz]

Follow up to silverstripe/silverstripe-elemental#1067

Check to see if the elemental "TopPage" feature would be useful here.

[emteknetnz]

I don't think it's useful in this situation

ElementalSiteTreeFilterSearch::applyDefaultFilters($query) - where $query is a DataList of SiteTree acts very similar to a composable extension. This means that other "extensions" could have already pre-filtered the DataList.

From there this method will go SiteTree -> get child ElementalArea's -> get child Elements -> see if database content match search term.

In order for the elemental TopPage feature, we'd need to reverse this and get all Elements -> see if database content matches search term, get TopPage (SiteTree) ... but only include results if the SiteTree wasn't already filtered

The existing method utilises eager loading to get all of the ElementalAreas and Elements in a pair of large DB queries, so performance wise it's fine.

My main concern to TopPage is that it was an optional extension in CMS 4, and on by default in CMS 5. It adds a TopPageID to BaseElement which is set onAfterWrite(). This means that many sites upgrading from CMS 4 to CMS 5 will unfortunately have a TopPageID = 0 for many elements

This rules this out as a robust solution