using `std::env::set_var` to set or change the value of either
DNS_TEST_SUBJECT or DNS_TEST_PEER is A Bad Idea, specially so when
tests are running in parallel
we can't forbid the use of `env::set_var` _but_ at least we can ensure
that even in its presence the return value of `dns_test::{subject,peer}`
will not change
this is accomplished using a "lazy" static variable that gets
initialized at most once during the lifetime of the process instead of
reading the env var each time `{subject,peer}` is called
to better convey the fact that the return value of `{subject,peer}`
won't change, we present them as static variables instead
When starting `hickory-dns` there is no easy way to check the start
sequence has finished & its fully ready to accept connections. Other
tools, e.g. unbound, are designed as services, they will correctly
manage their `pidfile`. They also could be queried by the `servicectl`
inside the Docker container.
the `start` constructor's parameter list was getting long and we want to
add even more configuration options, like EDE, in the future.
using the builder pattern lets us introduce new settings without
breaking changes
The RFC 9460 presentation syntax allows escaping the ',' list separator
in a `SvcParamValue` by writing `\,`. This commit updates `parse_list`
to handle this case.
Once this is done, one of the RFC 9460 test vectors using this feature
can be added to the unit tests. We don't yet support the more
complicated escaped comma using an escaped backslash for delimiter
escape so one remaining test vector for this is left out.
Previously the `FromStr` impl for `SvcParamKey` had support for parsing
the "arbitrary key" presentation syntax where a key can be specified
"keyNNNNN", where NNNNN is the numeric value of the key type without
leading zeros. The existing code would pull out the numeric component
into a `u16` and then use the `TryFrom<u16>` impl for `SvcParamKey` to
get the key.
However, the `TryFrom<u16>` impl for `SvcParamKey` was using the IANA
service parameter keys registry to map from u16s to `SvcParamKey`.
Values 0..6 are mapped to the known key entries. The reserved range
(65280-65534) was mapped to `SvcParamKey::Key`, and 65535 was mapped to
`SvcParamKey::Key65535`. This makes sense when mapping an arbitrary u16,
but when we are parsing a "keyNNNNN" presentation syntax item, we want
to represent it as `Key(NNNNN)`, no matter if it is/isn't a registered
key.
This commit fixes this behaviour, constructing a `SvcParamKey::Key()`
entry when parsing the arbitrary key presentation syntax, avoiding
`TryFrom<u16>`.
With this change in place the two arbitrary key test vectors can be
included in the svcb test vector unit test.
[0] https://datatracker.ietf.org/doc/html/rfc9460#name-initial-contents
See https://datatracker.ietf.org/doc/html/rfc9460#appendix-D
Tests that we can parse the presentation format for each of the positive
test vectors.
Possible follow-up work:
* Add the negative failure tests
* Add coverage for wire format matching expected
