Add Linode Provider, Cache DNS Entries, and Fix 2 Open Issues

[anonyco]

I put significant effort into ensuring this is a deceptively small change guaranteed to break nothing and cause you no issues:

• I tested this new version against upstream stalwart and stalwart builds and tests with no additional errors. (Baseline stalwart is currently failing with 20 or 21 errors prior to these changes.)
• I added unit tests for all the new features I'm adding
• I carefully documented all changes with descriptive commits and comments in the code
• I carefully broke up this PR into many bite-size commits, e.g. each of which builds and tests successfully. git bisect away!
• No publicly exported Rust APIs were changed in a breaking way, e.g. no variables were renamed in the process
• Only one new dependency—thiserror—as suggested by dns_update::Error does not implement std::error::Error #8. I checked thiserror's source code and, if I were to fix dns_update::Error does not implement std::error::Error #8 without adding thiserror, I'd end up duplicating half of the code in thiserror (and greatly increasing maintenance efforts of dns-update). Also, thiserror pulls in 0 subdependencies. I think it's a pretty unobjectionable decision to add the thiserror crate.
• I created a github-style squashed merge single commit thing as that seems to be the project style here

Three issues were not addressed by these changes:

• I suggest we close Consider reusing hickory_proto::rr::record_data::RData instead of own DnsRecord type #9 as WontFix because the Hickory Rust library is horrible at frequent massively breaking changes. Attempting to use Hickory's DNS entries would only lead to this project getting into a mess of trouble within a matter of months or weeks.
• Allow downstream users to be provider agnostic #6 and Allow being more specific in record deletions. #7 are great suggestions and I think I made some progress towards it with some of the refactoring I did, but my hands were extremely tied by the fact I avoided any breaking changes and there's no unit tests for Cloudflare or Digital Ocean to make sure we don't break those providers. I'm unsure how to proceed on those; I guess this is just a status update 👍

I hope this isn't too big of a change, and I hope you see the effort I put in to ensure my changes are as little hassle for you as possible 👍

[mdecimus]

Hi,

Thanks for the PR! A few comments:

• Remove the caching code, this library is a thin layer for DNS updates. Caching should be done in the application using this library.
• Please remove the thiserror dependency. We try to keep the number of external dependencies to a minimum.

[anonyco]

Hi,

Thank you for all the work you do on Stalwart. I removed the thiserror dependency but I'd like to confirm with you if removing the caching is what you really want to do before I remove it:

1. The application using the library can't cache the temporary domain/record IDs, and that's all my cache code caches. It's still up to the application to cache redundant requests. All my cache does is speed up common transaction patterns where you query a record, update it, and delete it all from the same DnsUpdater object. (Without my cache, each would require up to 2 additional HTTP requests to get the domain and record IDs for the transaction depending on the provider.)
2. The cache never changes the observed behavior of DnsUpdater; it only caches temporary domain/record IDs. These are unchanging constants for all DNS providers.
3. Error conditions aren't changed either for any DNS provider; API requests using cached domain/record IDs merely fail at the final transaction to the API server instead of at the upfront API request to fetch the domain/record ID (in the scenario an external actor deletes the domain/record while DnsUpdater is in use.)
4. The cache costs no overhead/baggage—it adds neither static globals nor additional dynamic memory allocation to DnsUpdater usage
5. I added unit tests for all the above cases in order to ensure the cache works properly.

I'll remove the cache if that's what you want, it's not my intention to obstruct. I just thought you didn't have the full info on the feature 👍

[mdecimus]

Hi, yes, please remove all caching code. This PR should only add Linode support. Other changes or improvements to the API can be discussed separately. However, caching is beyond the scope of this library even if it has zero cost.

[stappersg]

I'll remove the cache if that's what you want, it's not my intention to obstruct.

This PR should only add Linode support.

Yes, atomic commits for the win!