Enforce MD5 auth string invariants via new type

[taspelund]

Intoduces Md5AuthString type to wrap a String behind a fallible
constructor and immutable getters. This ensures that an API client is
unable to configure an MD5 auth key that does not comply with the
inputs recommended by RFC 2385 (TCP MD5 option for BGP):

4.5 Key configuration

   It should be noted that the key configuration mechanism of routers
   may restrict the possible keys that may be used between peers.  It is
   strongly recommended that an implementation be able to support at
   minimum a key composed of a string of printable ASCII of 80 bytes or
   less, as this is current practice.

The Illumos and Linux kernel implementations both accept 80-byte keys
with arbitrary contents, so the printable ASCII constraint is purely
coming from RFC 2385 and the need for keys to round-trip through json
via OpenAPI / Dropshot.

Fixes: #765

[taspelund]

The libnet dependency is also bumped in this ticket in order to pull in oxidecomputer/netadm-sys#210. This gives us an additional layer of checking around the MD5 auth keys we submit to the kernel.

[taspelund]

@rcgoodfellow @jgallagher I've rebased this on main and applied some fixes found during an AI code review.
If you guys have some time to look this over again, it would be much appreciated

[jgallagher]

Changes LGTM, just a couple small nits.

[nicolaskagami]

Always happy to see us enforcing invariants through types :)

Changes look good and straightforward, though the amount of boilerplate we need to add is a bit unfortunate.

I'd like to see @jgallagher's points addressed before merging, namely the v1 concern and the HttpError From impl.

Besides that, I noticed that we're changing the types from underneath the Db so we'll lose persisted neighbors that don't have a valid Md5AuthString in get_bgp_neighbors. That's probably fine, but I thought I'd point it out.

[taspelund]

I'd like to see @jgallagher's points addressed before merging, namely the v1 concern and the HttpError From impl.

These have been addressed in the most recent feedback commit.

Besides that, I noticed that we're changing the types from underneath the Db so we'll lose persisted neighbors that don't have a valid Md5AuthString in get_bgp_neighbors. That's probably fine, but I thought I'd point it out.

Yes, it definitely will. However, since the prior behavior was for maghemite to panic and we never received a bug report on this... I think it's probably safe to say no one has (successfully) deployed an invalid key 😁

[taspelund]

@nicolaskagami @jgallagher I've pushed another set of commits that address the latest round of feedback (HttpError conversion, v1 API type conversion fallibility) as well as a handful of issues identified during LLM code review.

There's a fair amount more lines that have been touched as a result of fixing some of the other type conversion issues that came up during the recent changes (e.g. reworking the rdb::Prefix <--> oxnet::IpNet type conversions to be fallible instead of calling .unwrap(), fixing some BGP capability type conversions to be fallible instead of mapping enum variants in an invalid way, etc.).

If you guys feel it adds too much noise into this PR, I can split it out into a separate one. Either way, this is ready for another review. Thanks!