When creating a match tree with a HTTP filter, the match tree is completely free form. We should add support for filters to specify validation rules, e.g. "this action cannot be resolved after request headers", which would run against any match tree configured for this filter and reject the configuration if the validations fail.

The simple way of doing this would be pass every unique tree traversal to the filter and have it validate that each path that results in specific actions match its validations. This would allow a filter to not only specify which input can be used to control its custom actions, but also HCM ones: for example, a filter might say that if a skip action is configured, it should do so using only headers. A filter might want to do this because it relies on seeing end_stream=true or similar after having processed headers.

To make this check a bit less brittle and open to the idea that you might have multiple matcher inputs that are based on request headers, we might want to add a concept to the various HttpMatchingData providers that allows us to generically indicate whether they require headers, data, etc.. For example, you could imagine both a RawRequestData and Base64RequestData input matcher indicate that they rely on request data. This would allow the filter to specify a category of inputs that are permitted, with the goal of ensuring that any match result is determined at specific stages in the stream lifetime. This then avoids filters having a direct dependency on the names of specific input extensions, allowing custom extensions to be added and still be permitted by filters.