add no-strict feature to ignore InvalidDirectives

[philgebhardt]

Fix for #17

It's sometimes desireable to ignore invalid directives so that the
supplied configuration can still be used. This change adds a feature
flag no-strict that when enabled, does not return an
Err(InvalidDirective(_)) when a directive isn't valid. Instead, it
skips over it, allowing the configuration to be used.

[tailhook]

Hm, can we make it a runtime feature rather than compile-time?

[philgebhardt]

@tailhook I suppose it could be implemented as a runtime feature. However that presents the problem of propagating such behavior up to dependent crates (such as https://github.com/bluejekyll/trust-dns). Implementing the switch at compile time gives the end user the ability to control the behavior, regardless of how this crate is used. Of course I'm biased toward the decision of compile time for this reason, but I'd expect this leads less configuration overall

[tailhook]

What's your specific use case? Do you put custom stuff into the resolv-conf? Or is it some directive on exotic system is not implemented?

[Coding-Badly]

There is a third use case... Most / all other software that uses resolv-conf ignores invalid entries. A system with a "poison" resolve-conf can seem perfectly normal. When a Rust application built with this crate is introduced to a system with a simple typographical mistake in resolve-conf, the Rust application appears to be buggy.

[djc]

Just a third-party opinion: while being strict about parsing is quite useful (and very much in line with the Rust ecosystem), I also feel like defaulting to matching existing tools in some amount of liberty makes sense. I think it makes sense to make this optional at runtime, but default to being more liberal. (Whatever is decided here, as a trust-dns maintainer I'm fine with exposing some API in trust-dns to allow access to useful runtime options.)

[Coding-Badly]

@tailhook, what problem do you hope to solve by making strict a run-time option?

[tailhook]

From the top of my head:

1. Features in cargo are additive, it means that if I'm having crate A that needs strict parsing and crate B that doesn't. Crate A will get non-strict parsing (whenever A and B are used in the same application).
2. If I would make some command-line that manipulates resolv-conf files I would do strict validation on writing, and might use loose validation on reading.
3. In my apps, I'd like loose check by default, perhaps with printing warnings (given the current state of the world), but strict for extra security (since name resolution is often an important part of the system security).

[tailhook]

That said I think it would be cool if would look like this:

Config::parse(xxx).or_else(|e| {
  log::warn("Resolv.conf issues: {}", e);
  e.loose_config()
})

I.e. something similar to how mutex poisoning work, where you can recover original value from error object.

[Coding-Badly]

...it would be cool if would look like this...

It would.

But that does not solve the problem presented by @philgebhardt. The application developer has determined that ignoring resolv.conf errors is the right choice. That decision needs to propagate throughout the application. The most effective way to make that happen is for this crate to ignore resolv.conf errors.