Prepare v1.0.0 release

[lvkv]

I think this library is in good enough shape to call a 1.0 release. Changes from v0.2.0, stolen from the GitHub release notes generator:

What's Changed

• Update non-breaking dependencies, .gitignore by @lvkv in Update non-breaking dependencies, .gitignore #20
• CI: Temporarily remove GitHub Actions workflows by @lvkv in CI: Temporarily remove GitHub Actions workflows #21
• Bench: Upgrade Criterion, fix lints by @lvkv in Bench: Upgrade Criterion, fix lints #23
• Tests: Add integration test harness by @lvkv in Tests: Add integration test harness #22
• Use higher-level libresolv crate by @lvkv in Use higher-level libresolv crate #26
• Chore: Resolve all Clippy lints by @lvkv in Chore: Resolve all Clippy lints #27
• Remove Trust-DNS resolver backend by @lvkv in Remove Trust-DNS resolver backend #28
• CI: Add cargo-readme check by @lvkv in CI: Add cargo-readme check #30
• CI/Docs: Fix broken doc tests and workflow by @lvkv in CI/Docs: Fix broken doc tests and workflow #31
• Refactor: Accept impl Into<String> over &impl ToString by @lvkv in Refactor: Accept impl Into<String> over &impl ToString #32
• Tests: Sandboxing without custom harness by @lvkv in Tests: Sandboxing without custom harness #33
• Add Hickory DNS resolver backend by @lvkv in Add Hickory DNS resolver backend #24
• Build/Docs: Upgrade HTTP, default to Hickory, remove Hyper by @lvkv in Build/Docs: Upgrade HTTP, default to Hickory, remove Hyper #34
• Build: Update to Rust edition 2024 by @lvkv in Build: Update to Rust edition 2024 #35

I haven't made the following changes, but am open to being convinced:

• Removing async-trait
• Moving to async closures instead of future-producing closures

CC @max-heller

[Copilot]

Pull request overview

This PR prepares the srv-rs crate for a v1.0.0 release by updating the crate’s published version and aligning user-facing documentation with the new release.

Changes:

• Bump crate version from 0.2.0 to 1.0.0 in Cargo.toml.
• Update the README dependency snippet to reference srv-rs v1.0.0.
• Update the authors metadata in Cargo.toml.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
README.md	Updates the Cargo.toml usage snippet to reference v1.0.0.
Cargo.toml	Bumps package version to 1.0.0 and updates package metadata (authors).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ping-deshaw2]

Minor review feedback:

• Error::Lookup is lossy, it doesn't preserve the stack trace of the underlying error, since we are using thiserror, this can be fixed by marking it #[from].
• sort_key should have documentation stating it is only an approximation of the running sum algorithm in RFC 2782.
• A bunch of public things could be Debug (Affinity, AffinityUriIter, Rfc2782)
• Accessing LibResolv can panic, there could be documentation for the panic when libresolv fails to initialize.
• AffinityUriIter could have a remaining: usize, so it can implement ExactSizeIterator.

[lvkv]

@ping-deshaw2:

• Error::Lookup is lossy, it doesn't preserve the stack trace of the underlying error, since we are using thiserror, this can be fixed by marking it #[from].
• A bunch of public things could be Debug (Affinity, AffinityUriIter, Rfc2782)
• Accessing LibResolv can panic, there could be documentation for the panic when libresolv fails to initialize.

Done.

• AffinityUriIter could have a remaining: usize, so it can implement ExactSizeIterator.

I decided against implementing this: there's not much (if any) benefit to the end user IMO

• sort_key should have documentation stating it is only an approximation of the running sum algorithm in RFC 2782.

This is the most interesting one. I wanted to make this RFC-compliant, but literally implementing the algorithm as specified in the RFC would've required a somewhat large refactor of the codebase. Instead, I heavily leaned on Claude to research an alternative implementation of sort_key that would preserve the same distribution. It now uses weighted random sampling (specifically algorithm A-Res). I've added a unit test for this to assert RFC-compliant behavior. There's wiggle room for interpretation, especially around how often records with weight 0 are selected in the presence of other records with non-zero weights within the same priority, but I'm quite satisfied with the result, especially when compared to the accuracy of the existing approximation. Definitely open to comments on this one.

[lvkv]

but I'm quite satisfied with the result

Aside from it being potentially overkill, potentially slower. I'll benchmark this, actually...

[lvkv]

I'll benchmark this, actually...

It came back over 3 times slower. Coupled with the decreased readability of that implementation, I decided to revert back to the original and add a comment about it being an approximation.