We must not have min TTLs that are not smaller than the max TTL.

I ran both isort and black.
Let's hope that this makes the CI happy.

This will come in handy for APIs not supporting TTL outside a certain range.
The Spaceship API, for example, only allows TTLs in the range of 5..3600 but rewriting a
whole zone for Spaceship only seems not as convenient as clamping the values as they flow
through OctoDNS.

The code is coming from Claude. My prompt was:

    Write a simple OctoDNS processor that clamps TTL values.

I followed up with:

    AttributeError: 'TtlClampProcessor' object has no attribute 'log'
    Where should self.log come from?

And finally:

    Hm. I suspect the code is not running, somehow. It doesn't seem to be getting control. I
    put a raise in the process_record method but it doesn't fail. And I don't see any clamped
    values nor log output.

So it took three attempts to make it produce something useful.

https://www.rfc-editor.org/rfc/rfc3403#section-4.3

warnings

Switches the processor to use process_source_and_target_zones which
happens later, during planning changes and thus happens seperately for
the source and aliased zones. This leaves the templates in the copy of
desired that Manager uses to start the alias process. The updated copy
is in the plan so externally everything will still make sense and
behave as expected.

Signed-off-by: Ivan Schaller <ivan@schaller.sh>