This is kind of gross.

Omicron currently is out of sync with maghemite, see #6693 and the two
maghemite pushes that require synchronization:
oxidecomputer/maghemite#359 and
oxidecomputer/maghemite#360. I'd like to make
forward progress with the hyper v1 migration, and that's blocked on
updating the omicron dependency of maghemite which pulls in old hyper
(reqwest, progenitor, etc). This gets pull into other repos via
omicron-common.

It's worth noting that this circular arrangement seems lousy. The
"vassal crates" (crucible, propolis, maghemite, (and dendrite to a
lesser degree)) depend on omicron-common, but omicron-common pulls in
maghemite's `mg-admin-client` which in turn pulls in... lots...
including progenitor, hyper, reqwest, etc.

My goal here is to have a temporary dependency on a branch of maghemite
(oxidecomputer/maghemite#378); once #6693 is
integrated, we can then pin the dependency on maghemite's HEAD rev.

I renamed the `local_pref` column to `rib_priority` to complete the
rename in #6693.

I also changed the type of the renamed column from `INT8` to
`INT2`, clamping existing values to `0` or `255`. This was missed
in #6693 and led to the
following error when reading the value from the database.

```
{"msg":"request completed","v":0,"name":"omicron-dev","level":30,"time":"2025-07-11T13:57:48.670343242Z","hostname":"ms-ox01","pid":3113,"uri":"/v1/system/networking/switch-port-settings","method":"POST","req_id":"12b35f5a-2255-4244-a5aa-f9c84032fb81","remote_addr":"127.0.0.1:41766","local_addr":"127.0.0.1:12220","component":"dropshot_external","name":"e6bff1ff-24fb-49dc-a54e-c6a350cd4d6c","error_message_external":"Internal Server Error","error_message_internal":"Unknown diesel error creating SwitchPortSettings called \"example\": Error deserializing field 'local_pref': Received more than 2 bytes while decoding an i16. Was an Integer expression accidentally marked as SmallInt?","latency_us":133766,"response_code":500}
```

The error occurred because the Rust type was `SqlU8` and the database
type was `INT8`. Reads would fail because `INT8` columns could not be
read into `SqlU8` types without loss of precision.

This was caught in
oxidecomputer/terraform-provider-oxide#426
when implementing a Terraform provider resource for switch
port settings. It's likely that this has been broken since
#6693 and any user that
attempted to set `rib_priority` in their Rack Setup Service (RSS) would
have encountered this error. However, `rib_priority` is an uncommon
configuration option and none of our customer's RSS configurations show
this as being set.

Given this information, it seems safe to assume that no customer has the
`rib_priority` column set so the clamping logic implemented here should
work well for customer installations.

I renamed the `local_pref` column to `rib_priority` to complete the
rename in #6693.

I also changed the type of the renamed column from `INT8` to
`INT2`, clamping existing values to `0` or `255`. This was missed
in #6693 and led to the
following error when reading the value from the database.

```
{"msg":"request completed","v":0,"name":"omicron-dev","level":30,"time":"2025-07-11T13:57:48.670343242Z","hostname":"ms-ox01","pid":3113,"uri":"/v1/system/networking/switch-port-settings","method":"POST","req_id":"12b35f5a-2255-4244-a5aa-f9c84032fb81","remote_addr":"127.0.0.1:41766","local_addr":"127.0.0.1:12220","component":"dropshot_external","name":"e6bff1ff-24fb-49dc-a54e-c6a350cd4d6c","error_message_external":"Internal Server Error","error_message_internal":"Unknown diesel error creating SwitchPortSettings called \"example\": Error deserializing field 'local_pref': Received more than 2 bytes while decoding an i16. Was an Integer expression accidentally marked as SmallInt?","latency_us":133766,"response_code":500}
```

The error occurred because the Rust type was `SqlU8` and the database
type was `INT8`. Reads would fail because `INT8` columns could not be
read into `SqlU8` types without loss of precision.

This was caught in
oxidecomputer/terraform-provider-oxide#426
when implementing a Terraform provider resource for switch
port settings. It's likely that this has been broken since
#6693 and any user that
attempted to set `rib_priority` in their Rack Setup Service (RSS) would
have encountered this error. However, `rib_priority` is an uncommon
configuration option and none of our customer's RSS configurations show
this as being set.

Given this information, it seems safe to assume that no customer has the
`rib_priority` column set so the clamping logic implemented here should
work well for customer installations.

I renamed the `local_pref` column to `rib_priority` to complete the
rename in #6693.

I also changed the type of the renamed column from `INT8` to
`INT2`, clamping existing values to `0` or `255`. This was missed
in #6693 and led to the
following error when reading the value from the database.

```
{"msg":"request completed","v":0,"name":"omicron-dev","level":30,"time":"2025-07-11T13:57:48.670343242Z","hostname":"ms-ox01","pid":3113,"uri":"/v1/system/networking/switch-port-settings","method":"POST","req_id":"12b35f5a-2255-4244-a5aa-f9c84032fb81","remote_addr":"127.0.0.1:41766","local_addr":"127.0.0.1:12220","component":"dropshot_external","name":"e6bff1ff-24fb-49dc-a54e-c6a350cd4d6c","error_message_external":"Internal Server Error","error_message_internal":"Unknown diesel error creating SwitchPortSettings called \"example\": Error deserializing field 'local_pref': Received more than 2 bytes while decoding an i16. Was an Integer expression accidentally marked as SmallInt?","latency_us":133766,"response_code":500}
```

The error occurred because the Rust type was `SqlU8` and the database
type was `INT8`. Reads would fail because `INT8` columns could not be
read into `SqlU8` types without loss of precision.

This was caught in
oxidecomputer/terraform-provider-oxide#426
when implementing a Terraform provider resource for switch
port settings. It's likely that this has been broken since
#6693 and any user that
attempted to set `rib_priority` in their Rack Setup Service (RSS) would
have encountered this error. However, `rib_priority` is an uncommon
configuration option and none of our customer's RSS configurations show
this as being set.

Given this information, it seems safe to assume that no customer has the
`rib_priority` column set so the clamping logic implemented here should
work well for customer installations.

I renamed the `local_pref` column to `rib_priority` to complete the
rename in #6693.

I also changed the type of the renamed column from `INT8` to `INT2`,
clamping existing values to `0` or `255`. This was missed in
#6693 and led to the
following error when reading the value from the database.

```
{"msg":"request completed","v":0,"name":"omicron-dev","level":30,"time":"2025-07-11T13:57:48.670343242Z","hostname":"ms-ox01","pid":3113,"uri":"/v1/system/networking/switch-port-settings","method":"POST","req_id":"12b35f5a-2255-4244-a5aa-f9c84032fb81","remote_addr":"127.0.0.1:41766","local_addr":"127.0.0.1:12220","component":"dropshot_external","name":"e6bff1ff-24fb-49dc-a54e-c6a350cd4d6c","error_message_external":"Internal Server Error","error_message_internal":"Unknown diesel error creating SwitchPortSettings called \"example\": Error deserializing field 'local_pref': Received more than 2 bytes while decoding an i16. Was an Integer expression accidentally marked as SmallInt?","latency_us":133766,"response_code":500}
```

The error occurred because the Rust type was `SqlU8` and the database
type was `INT8`. Reads would fail because `INT8` columns could not be
read into `SqlU8` types without loss of precision.

This was caught in
oxidecomputer/terraform-provider-oxide#426 when
implementing a Terraform provider resource for switch port settings.
It's likely that this has been broken since
#6693 and any user that
attempted to set `rib_priority` in their Rack Setup Service (RSS) would
have encountered this error. However, `rib_priority` is an uncommon
configuration option and none of our customer's RSS configurations show
this as being set.

Given this information, it seems safe to assume that no customer has the
`rib_priority` column set so the clamping logic implemented here should
work well for customer installations.