feat: Implement authoritative DNS check for acme challenge

[ghost]

Closes #20

[humphd]

This looks pretty good. A few questions and small things to fix.

Another question I have in general: there's a lot of places this code can/will throw. Are we going to leave-out exception handling for most internal calls, and leave it to the caller to deal with? Is there anything in this code you want to log (debug logs) or errors we should be surfacing with more meaningful error messages?

[ghost]

This looks pretty good. A few questions and small things to fix.

Another question I have in general: there's a lot of places this code can/will throw. Are we going to leave-out exception handling for most internal calls, and leave it to the caller to deal with? Is there anything in this code you want to log (debug logs) or errors we should be surfacing with more meaningful error messages?

If anything goes wrong, we do want this to fail causing the queue job to restart, and the exceptions contain meaningful error messages that can be caught and re-thrown by the logic of the queue worker.

To help with maintainability, I'm trying to limit the scope of this class, to only work with let's encrypt, and have no knowledge at all about SQL or the queue system.

At the moment I don't see the need to add additional debug logging, but if you think there are places that we would benefit on keeping an extra eye on, I'd be happy to add them (error handlig and logging should still be only happening in the queue worker code)

[humphd]

At the moment I don't see the need to add additional debug logging, but if you think there are places that we would benefit on keeping an extra eye on, I'd be happy to add them (error handlig and logging should still be only happening in the queue worker code)

OK, let's continue with this approach, and keep an eye on things as we add tests. Layering in logging later is often much harder.