VehicleRestriction could absorb road class and turn restrictions

[nreinicke]

PR #204 introduced the concept of the VehicleRestriction.

@robfitzgerald points out that:

if you think about it, the mechanism for these restrictions is the same as the turn restrictions and road class restrictions. we could just absorb them here:

  pub enum VehicleRestriction {
      MaximumTotalWeight((Weight, WeightUnit)),
      MaximumWeightPerAxle((Weight, WeightUnit)),
      MaximumLength((Distance, DistanceUnit)),
      MaximumWidth((Distance, DistanceUnit)),
      MaximumHeight((Distance, DistanceUnit)),
      MaximumTrailerLength((Distance, DistanceUnit)),
      RoadClass(u8),
      TurnRestriction(EdgeId, EdgeId)
  }

then we generalize VehicleParameter to RestrictionParameter. A RoadClass restriction parameter is a RoadClass(HashSet(u8)) or whatever deserialized off the query. it would tidy things up since they all have the same logic

[robfitzgerald]

note: wrote this, then talked myself out of it, leaving it here for posterity.

had a thought about this. still thinking that the right path is an enum. wondering if there's a smart way to do this more generally, since we are proposing this work in the base repo. could we reduce the above into:

#[derive(Serialize, Deserialize)]
pub enum VehicleRestriction {
    EdgeWeightRestriction(???),
    EdgeDistanceRestriction(???),
    // ... other units
    NumericClassRestriction(u8),
    TrajectoryRestriction(Vec<EdgeId>)
}

downstream, a user could compose these as a CombinedFrontierModel.

thing is, that stuff in the ??? would need to be open enough in it's design to handle things like "expect a number on the query at the key axles, then multiply that by a key weight, and then do a <= operation."

eh, that's writing a whole nuther DSL, and it sounds awesome, but maybe that's future work to revisit later.