StateFeature registration via config, service.build, user query

[robfitzgerald]

In order to more clearly delineate between TraversalModels in a hierarchical arrangement, we can enforce that any TraversalModel "registers" the feature it updates.

This would assert the following conventions + code changes:

1. state features should not be defined at the root of the TOML in a [state] section, but instead, always come from traversal model configuration
2. each traversal model implements TraversalModel::register_features() (currently state_features()) and returns the state features that it updates
   • if a traversal model depends on a feature from an inner model (hierarchical traversal models), it does not register the feature, but instead, assumes that the features has been registered by the inner model
   • bonus points: the feature names are parameterized in the config JSON used to build a model, allowing us to define the (somewhat arbitrary) feature names at config time
3. StateModel collects these and builds a state representation as currently implemented
4. Remove StateModelService
   • we no longer persist StateModel feature configurations
   • we no longer define a top-level [state] in the TOML with globally-set state features

[robfitzgerald]

@nreinicke thinking of re-writing this one, expanding on the idea to a sort of general approach to registering state features with the state model:

1. state features should not be defined at the root of the TOML in a [state] section, but instead, always come from traversal model configuration
2. each traversal model implements TraversalModel::state_features() and returns the state features that it updates
   • if a traversal model depends on a feature from an inner model (hierarchical traversal models), it does not register the feature, but instead, assumes that the features has been registered by the inner model
3. StateModel collects these and builds a state representation

thinking maybe we rename TraversalModel::state_features() to TraversalModel::register_features() to make this clear. along the way, this would set up the DistanceTraversalModel the way this issue currently describes.

what do you think? does this clean things up?

[nreinicke]

Yeah I like this idea, having the default state features come from the traversal model. Then, at query time, the user could propose a new initial condition for any state feature. If it exists in the state vector that was built by the traversal model it will update it, or, if it doesn't exist, either ignore that parameter or fail.

[robfitzgerald]

I think this happens for the most part, but, I don't think user queries can update the state model yet, so I'm keeping it open until we resolve that capability.