Add documentation on automatic use of Multihop when DAITA is enabled

[MarkusPettersson98]

This PR updates relay-selector.md to reflect that multihop may be used when DAITA is enabled to select a DAITA-compatible entry relay if needed.

TODO

Maybe we should mention that this behavior also overrides multihop since #6996?

---

This change is 

[linear]

DES-1356 Document DAITA overriding Multihop in relay selector

[Serock3]

Reviewed 1 of 1 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @jbjorkang and @MarkusPettersson98)

---

docs/relay-selector.md line 16 at r1 (raw file):

  for its obfuscating properties, not for any security properties it might have.
- DAITA - Short for "Defense against AI-guided Traffic Analysis". A technique supported on some
  WireGuard relays that makes website fingerprinting more difficult by sending random padding

I may be more future proof to not mention just adding padding packets, e.g. "...that makes fingerprinting more difficult by introducing network noise and making all packets the same size"

[MarkusPettersson98]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @jbjorkang and @Serock3)

---

docs/relay-selector.md line 16 at r1 (raw file):

Previously, Serock3 (Sebastian Holmin) wrote…

I may be more future proof to not mention just adding padding packets, e.g. "...that makes fingerprinting more difficult by introducing network noise and making all packets the same size"

Now that you mention it, I don't think we need to define how DAITA works, only what the technique is intended to achieve. What do you think about the following statement:

- DAITA - Short for "Defense against AI-guided Traffic Analysis". A technique supported on some
  WireGuard relays that makes website fingerprinting more difficult.

?

[hulthe]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @jbjorkang and @Serock3)