perf: in adding answers, use static dispatch instead of dynamic dispatch

[CosminPerRam]

This is an alternative to #206, changes the answer type from Box<dyn DnsRecordExt> to impl DnsRecordExt + Send + 'static.

This replaces the usage of dynamic dispatch on every function call with static dispatch, which in our case should be faster as we always call these functions with new instances (Box::new(...)), so the compiler should be able to monomorphize and/or optimize further its usage, as all the possible implementations are now known at compile time.

The dynamic dispatch is still needed for the answer field (Vec<(Box<dyn DnsRecordExt>, u64)>) in self.answers.push of add_answer_at_time, but this is done only if needed (when if conditions are met), so this should provide us with only performance improvements, please note that I'm not really a Rust expert or anything, nor have I done benchmarks to provide this (maybe we could add some eventually?).

Edit: forgot to mention that the disadvantages of static dispatch are longer compile times and larger binary size (but I haven't seen significant changes in these)

[CosminPerRam]

The compiler automatically implements Send on appropriate types, but as we have only usages of this now, it's a little bit more concise to explicitly state it on the trait rather than on the Box (and not in the answer functions), theoretically at least, should be the same thing but I think stating it like this rather than how it was is a bit better, what do you think?

[keepsimple1]

I think it is odd to have DnsRecordExt trait to conform Send, because this trait is really just about supporting different types of DNS records, nothing related to dispatching mechanisms (e.g. Send or Sync, etc).

I can understand that moving Send to the trait would simplify the parameter signature in functions, but it doesn't feel the right reason for me.

[keepsimple1]

On the grand scheme, I think the performance difference is small / not significant for this lib, unless we have some measurement data showing a problem. But It's a learning opportunity for me to understand more about dynamic dispatch and static dispatch in Rust.

This replaces the usage of dynamic dispatch on every function call with static dispatch,

For my understanding, do you have a pointer to Rust doc or something similar to verify that? I don't know for sure, and asked ChatGPT, and here is what it says:

...even with the impl Trait syntax, dynamic dispatch will still be used when calling the add_additional_answer function because answer is still treated as a trait object. ...

Is ChatGPT hallucinating here?

[keepsimple1]

Although I'm not sure about the static dispatch thing, I see the benefit of not requiring the callers to add Box::new() at the call site. So I'm okay with such change, for ease of use, not for the performance reason.

And I think I prefer to have Send in here (if needed), compared to move Send into DnsRecordExt trait, as I mentioned in another comment.

[CosminPerRam]

Is ChatGPT hallucinating here?

Asking ChatGPT (4) about this says that this statement is incorrect, I think it says that it still implies dynamic dispatch as we eventually use .push(Box::new(answer)).

Here is how Brandeis University explains what is static and dynamic dispatch and their advantages and disadvantages. Here is a shorter example and explanation.

I see the benefit of not requiring the callers to add Box::new() at the call site. So I'm okay with such change, for ease of use, not for the performance reason.

Fair enough, if I will get the time I'll try to make some benchmarks just as a curiosity (:

[keepsimple1]

LGTM, thanks!