Change the MSRV policy and bump to 1.79.0

[bal-e]

The MSRV is being bumped so that domain can access newer language features. In particular:

• <[u8]>::utf8_chunks() (1.79) is very useful for processing byte strings that will mostly contain valid UTF-8 text.
• core::net (1.77) allows us to remove our polyfills of Ipv4Addr etc., used when the std feature is disabled.
• async fn and return-position impl Trait in traits (1.75) allow us to define traits using async fn, avoiding the overhead of Box<dyn Future> for un-nameable future types.
• Option::is_some_and() (1.70) simplifies a very common pattern when inspecting optional values.

The MSRV bump policy is also being updated; it sets a maximum MSRV (relative to the latest stable Rust version) and documents the conditions under which a bump will occur.

[Philip-NLnetLabs]

I think the 4 versions behind rule is fine if we want to use new features. But if we don't need any features from 1.80.1 then er is no reason to bump it to that version.

[bal-e]

I agree. For reference, here's a list of notable features since 1.68.2:

• 1.80: <[u8]>::trim_ascii(), LazyLock, exclusive ranges in patterns
• 1.79: associated type bounds (T: Trait<Assoc: Bound>), better borrow checking, <[u8]>::utf8_chunks
• 1.78: custom diagnostic messages
• 1.77: C string literals, recursive async fns, core::net::{Ipv4Addr,Ipv6Addr}
• 1.75: async fn and return position impl Trait in traits, pointer byte offsets
• 1.70: Option::is_some_and()

I don't think 1.80 is strictly necessary, but utf8_chunks from 1.79 would be quite helpful (for formatting labels and domain names, which are usually -- but not always -- ASCII text).

[Philip-NLnetLabs]

I think we should also have a policy that the MSRV bump comes with the code that needs the new features or if the MSRV is in anticipation, then the commit should describe the reason for the bump.

[bal-e]

I'd rather keep MSRV bumps separate from the code that's using them, but I absolutely agree that the MSRV bump commit should document why the bump is happening and what features will be used. I'll add a note about it.

[bal-e]

There has been previous discussion about MSRV bumps at #322. @vavrusa, I just wanted to check that the proposed MSRV policy (i.e. MSRV is at least 4 versions behind stable, or older) is compatible with your use case.