Add wireformat buffer to DnsResponse

[mattias-p]

This PR adds a wireformat buffer to the DnsResponse struct, allowing the caller to know the exact bytes that were received in a given response.

This is my second attempt at achieving the same goal. During the review of my first attempt (#1823) @djc suggested an alternative approach. We refined his idea a little and agreed that it seemed like a better way. This is an implementation of that idea.

Fixes #1814.

[djc]

This looks pretty good to me!

[mattias-p]

I rebased this PR for two reasons:

• CI gave me some new clippy errors unrelated to these changes, and a clippy fix landed on main.
• I had a conflict in crates/resolver/src/error.rs.

When resolving the conflict I also integrated the two clean up commits.

I also realized that <trust_dns_client::rr::dnssec::tsig::TSigner as MessageFinalizer>::finalize_message() was creating a DnsResponse from a buffer without including the buffer in the DnsResponse, so I added a new commit for that.

[mattias-p]

For a while I was worried that it would be confusing for people to know if the buffer is supposed to be Some or None. But it should be intuitive enough, right? I.e.:

• When you're sending a response it's None.
• When you're receiving a response it's Some.
• When you call DnsResponse::new() yourself you know what you did.

I tried to come up with ways to make the API foolproof but I was unable to come up with something that carries its own weight.

[mattias-p]

I had a closer look at the circumstances in which DnsResponses are constructed. In production code a buffer i always available, and in test code a buffer is seldom (never?) available. But in test code we could afford to serialize a buffer from the Message just so we can construct a DnsResponse, right? This way we can make the DnsResponse buffer into a plain Vec<u8> without the Option, and it always contains something that was received. From my point of view this is a much nicer API.

In the test code there are lots of places where a Message is constructed and a DnsResponse is built from that. I thought it was best to keep that constructor for that. But to avoid accidentally creating DnsResponses with generated buffers I thought it best to not use a special method instead of From.

The QuicStream::receive() method used to return a Message but I changed it to return DnsResponse instead to give the caller access to the buffer.

I have a changeset implementing the above but the commits are in a mess so I need to clean them up before I push them.

[mattias-p]

I updated DnsResponse so that its buffer isn't wrapped in an Option but rather is always present.

To mitigate the risk of callers unintentionally synthesizing buffers for DnsResponse I replaced the impl From<Message> for DnsResponse with DnsResponse::from_message(). I'm not confident this is the best choice for placement and naming of this method but it is what I came up with. If you have a better suggestion I'll happily perform the search/replace.

[djc]

To mitigate the risk of callers unintentionally synthesizing buffers for DnsResponse I replaced the impl From<Message> for DnsResponse with DnsResponse::from_message(). I'm not confident this is the best choice for placement and naming of this method but it is what I came up with. If you have a better suggestion I'll happily perform the search/replace.

If this is only used in test code as you suggested earlier, we could guard the from_message() method with #[test]? I guess we might still want to expose it as a convenience to downstream crates?

[mattias-p]

If this is only used in test code as you suggested earlier, we could guard the from_message() method with #[test]? I guess we might still want to expose it as a convenience to downstream crates?

It's already used by test code downstream in the client, resolver and server crates as well as in the integration-tests. I tried marking it with #[cfg(test)] but the other crates can't access it then, even when running their own tests.

[bluejekyll]

I like how this is narrow to just the DnsResponse type. Looks good.