NLnetLabs
Introduce a replacement for `base::name`
The base::new_name module seeks to provide a simpler and more ergonomic interface for working with domain names. Its core types, Name, RelName, etc., are not generic over an underlying octets type: they are simple unsized byte slices, which can be stored in any container. This greatly simplifies their API and makes their methods more amenable to optimization.
The idea is to gradually replace the use of base::name with base::new_name across the crate, and eventually to remove base::name and let base::new_name take its place. Given the large number of modules in the crate, this will likely take a while.
While most of the functionality of base::name has been replicated, some things have been explicitly omitted. The ToName and ToRelativeName traits have been dropped, so that most domain name functionality is supported on Name/RelName etc. but not on Chain or ParsedName. Since domain names are so small (usually less than 64 bytes, always less than 256 bytes), ParsedName objects can be copied out into regular Names before being used. By relying on direct byte slice operations, basic methods like domain name comparison have been sped up (from quadratic to linear time, in fact).
@partim, @Philip-NLnetLabs: I'd like to hear your opinion on base::new_name::octets. I'm still thinking about what this interface should look like -- at least some names will have to be changed. Do you think it represents a good fit for byte slices with bounded sizes? Where should this module be placed? (does it fit in octseq?) And do we need Bytes-like functionality on top of it? (while Arc<Name> works, that does not offer slicing support).
This PR has been superseded by #474. However, it still contains functionality that may be included in that PR as the need arises.
Keeping this open because @bal-e wants to reference the idna code here.
