With this change, a new config option Subrealms is introduced into the realm config block.

The idea is to allow for a much cleaner configuration file without to many regexes, which are prone to human error in many ways. (Forgetting backslash before dot, inaccurate matching groups, not easy to read and understand, ...)

Instead of cumbersomely writing realm /@([^@]*\.)?example\.com$/ to match the realm together with all sub-realms, you now can simply write

realm example.com {
  Subrealms Include
  server my-example-server
  [...]
}

Since non-regex realm configurations are internally converted to regexes anyway, this configuration option is just a shortcut.
The given options are:

• No : Default, Same behavior as before (example.com -> @example\.com)
• Include : Include all subrealms, as well as the base realms (example.com -> @([^@]*\.)?example\.com)
• Only : Include only subrealms, but not the base realm (example.com -> @[^@]*\.example\.com)

Anoter goal of this patch is to fix some dynamic lookup problems.
Especially with a default route, dynamic lookups can cause loops if subrealms are not specified explicitly, but due to a NAPTR records, they are routed to the own server by the upstream server.
A working, simple configuration could look like this:

realm example.com {
  server my-example-server
}
realm example.com {
  Subrealms Only
  replymessage "Subrealms of example.com are not routed!"
}
realm * {
  server my-upstream-server
}

Open Discussion Points / Untested code / WIP-Points:

• The introduction of the new config option required a change in the addrealm() function signature. This function is also used in adddynamicrealmserver. I have not yet fully understood the whole code, so there may be some additional changes necessary.
• The realm struct already has a list subrealms, that, as far as I understood, is used for dynamic server lookups. This is a potentially confusing overload of the term 'subrealm' in the code.