feat: add VayDNS transport support

[FarmehrF]

added vaydns support for the backends

[crazydi4mond]

Thanks @FarmehrF for sending this PR. We really appreciate it.

Since we recently have implemented a lot of new features and changes on VayDNS, I wonder if you can help us out here with updating this PR? There are also some new flags added recently to VayDNS needed to be supported here as well with proper default values.

Also to simplify the process and to keep this PR more focused, I'd suggest ignoring -record-type for now and add a hard-coded -record-type txt flag to the transport command as it is already supported in the router. Later we will extend the internal DNS router of DNSTM and will add support for the other record types to make this flag configurable via TUI/CLI.

[FarmehrF]

Hi @crazydi4mond — thanks for the review and for spelling out what you wanted from the VayDNS side.

Here is what this branch does now:

Alignment with current VayDNS defaults

Server-side idle/keepalive defaults in config match upstream: 60s / 10s for native VayDNS, and 2m / 10s when dnstt_compat is enabled (mirroring vaydns-server behaviour with -dnstt-compat).
clientid_size defaults to 2 for native mode; we do not pass -clientid-size when compat is on (server fixes ID size at 8).
ApplyDefaults, validation (keepalive < idle, parseable durations, non-negative clientid_size), and buildVayDNSTunnel were updated accordingly.
Pinned vaydns-server / vaydns-client to v0.2.4 in internal/binary/binary.go.
CLI / TUI

Interactive tunnel add for VayDNS asks whether to use DNSTT-compatible wire format.
Non-interactive flow exposes dnstt_compat and clientid_size when transport is VayDNS.
About -record-type txt

You asked to hard-code -record-type txt on the vaydns-server command. I tried that first, but in practice several deployed servers still run builds that do not define -record-type, which causes flag provided but not defined: -record-type and the unit exits. To keep dnstm usable on those hosts, the generated ExecStart omits -record-type; behaviour stays TXT where that is the default, and older binaries keep working. If you prefer, we could add an optional config knob later (e.g. “emit record-type when supported”) or gate on version — happy to follow your preference.

[crazydi4mond]

@FarmehrF As DNSTM does not support VayDNS atm, -record-type flag not being supported on the older VayDNS versions shouldn't cause any issue as this would be the first DNSTM version supporting VayDNS. But I agree with you, since -record-type is set to TXT in the new version by default when the flag is missing, it is simpler to just avoid adding that flag to the transport binary. Later when we support the other record types in DNSTM DNS router, we can add this flag and make it configurable.