Simplified route config

[Tratcher]

#9 The existing routing rules system uses a single config entry named ‘rule’ and then uses a secondary parser to parse out entries for Host, Path, Methods, etc.. I've worked at simplifying this to use the normal config system with separate entries for the various components.

Before:

      "Routes": [
        {
          "RouteId": "backend1/route1",
          "BackendId": "backend1",
          "Rule": "Host('localhost') && Path('/{**catchall}') && Method(‘GET’, ‘POST’)"
       }
      ]

After:

       "Routes": [
         {
           "RouteId": "backend1/route1",
           "BackendId": "backend1",
           "Methods": [ "GET", "POST" ],
           "Host": "localhost",
           "Path": "/{**catchall}"
         }
       ]

Benefits:
• Slightly reduced complexity for the config
• Unified syntax
• Significant reduction in the code required to read and process config, everything uses the default config binder
• Removes a dependency on Superpower 2.3.0 that was being used to parse the custom format
• You don’t have to deal with invalid combinations like having duplicate entries for Host.
• Removes incomplete code paths like support for OR (“||”). That scenario can be supported by adding a second route.

Downsides:
• I haven’t found any yet

I have not added support yet for things that weren't already supported like headers, but have noted where they'd be added.

[stephentoub]

We should consider constructing this Regex with RegexOptions.Compiled. We wouldn't do that if this code is rarely used, if the perf of this doesn't matter, or if we expect lots of these _hostNameRegex instances and are worried about higher memory consumption.

(Though looking again, this is actually static, so number of these shouldn't be an issue. I was thrown off by the style difference from dotnet/runtime, where a s_ prefix would be used for static and _ is used for instance.)

[Tratcher]

Let's come back to that. I have my doubts that this level of validation is even needed. Filed #25

[davidni]

@Tratcher I'd really prefer if all fields related to inoming request matching were grouped together. Have you considered putting them in a matcher or rule section within the route? Since routes can have additional settings such as rate limiting etc. things could get messy very fast.

[Tratcher]

@Tratcher I'd really prefer if all fields related to inoming request matching were grouped together. Have you considered putting them in a matcher or rule section within the route? Since routes can have additional settings such as rate limiting etc. things could get messy very fast.

Like this?

       "Routes": [
         {
           "RouteId": "backend1/route1",
           "BackendId": "backend1",
           "Match": {
             "Methods": [ "GET", "POST" ],
             "Host": "localhost",
             "Path": "/{**catchall}"
           }
         }
       ]

Sure, that's easy. @halter73, this is also what you'd proposed on the mail thread?