Show image size on image picker; clean up empty metadata; small color fix

[charliepark]

This PR does a few things:

1. Per Show image size on image picker #1824, it adds the size of the image to the option in the image picker. It rounds the image size to one decimal place. (We already had a bytesToGiB function that defaulted to 2 decimal points; I updated that function to receive a digits prop (like the round function's prop) and set it, in this case, to 1 decimal point.) Note: Late in testing I noticed … it appears that the API is sending back an already-rounded-to-the-next-largest-GiB value, so we should look into whether that behavior is expected/wanted, though we can do that in a separate PR.
2. Per Image name looks bad when OS and/or version are empty #1777, it cleans up the label when data is missing from the image metadata (e.g. os, version). There might be some changes to the image upload form to change how that metadata is handled, but this at least makes it less awkward if data is missing. As there'll be the image's size now, there'll probably always be some data, but we won't have the awkward comma delineation we currently have when some data is missing.
3. Per Active image select item should use accent colour #1830, it fixes the color of the metadata in the selected listbox item.

When decimals are showing below, it's because I forced a larger size. But these screenshots show what would happen:

---

Up in item 1, I noted that the API is reporting image sizes as the next GiB up. Here you can see the API response calling the images, with this particular file reporting a size of 1073741824:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
console	✅ Ready (Inspect)	Visit Preview	Dec 6, 2023 7:53pm

[david-crespo]

we stan a testing king

[charliepark]

Haha, I was mostly trying to figure out why my 1.2GiB image kept getting represented as 2GiB, and hadn't yet looked at the API response. This is probably ultimately just testing Math.round, but I figured we could keep it around.

[david-crespo]

I don't get what you mean about the API rounding up — you can show me tomorrow.

[david-crespo]

Ah, I think I know what's going on there. Images are created from snapshots, and snapshots are created from disks. Even in the case of images uploaded directly through the console, the way it works is: we create a disk in a special importing state, upload the file to it in chunks, then snapshot it and turn the snapshot into an image. But disk size is required to be an integer multiple of 1 GiB:

https://github.com/oxidecomputer/omicron/blob/001143cf3b686b8cb4a72916e9f775a0a186df9b/nexus/src/app/disk.rs#L164-L174

So in practice it would seem the rounding really isn't necessary. I'd leave it in anyway.

[benjaminleonard]

Small tweak to match component in Figma library

[benjaminleonard]

Added this because it's visually correct but using the disabled token here is bad vibes. We should extend the accent tokens to add a quaternary step which is equivalent to it so that it's a little more semantic.

If you're interested the accent and content tokens don't have quite so many steps in them because you can't squeeze out as much contrast from the colours as you can from neutrals.

[benjaminleonard]

@charliepark Let me know if you want to run through the process of updating the colour tokens with me.

[charliepark]

Just wanted to add a screenshot to log the color updates from Ben's commit:

[david-crespo]

Random thought, not sure if it needs a fix here or in the API — if OS and version can be non-empty whitespace-only strings (and I think they can) then this will still show the weird empty spot. We should probably reject such a string API-side, so I'm inclined not to give it special handling here.