Add user_data field to instance create

[benjaminleonard]

Fixes #800 as per: #800 (comment)

Works fine with the mock API, we should test against dogfood.
We're just reading their file as a string and converting into a base64 string using the same mechanism as cert upload. Do we want to constrain the files a user can upload?

[vercel]

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

Name	Status	Preview	Updated (UTC)
console	✅ Ready (Inspect)	Visit Preview	Jan 23, 2024 8:06pm

[david-crespo]

This looks good to me functionally. The tooltip/help text could use workshopping.

For one thing, if we're going to have help text anyway, I don't think we need the tooltip. The whole section is already collapsed under Advanced. Might as well put all the text in the help text.

More importantly, though, we should explain better what this content is supposed to be (the API doc this is based on could use the same improvement). As discussed in chat, it would make things a lot easier if we could be specific an say "this is about cloud-init" rather than "instance initialization systems (such as cloud-init)". Just so I'm not complaining without making a constructive suggestion, here is some text that is IMO at least a marginal improvement on what's there:

Data or scripts to be passed to cloud-init as user data (examples) if the selected boot image supports it. Maximum size 32 KiB.

In lieu of our own doc explaining this at length, this at least gives them something. I'm on the fence about whether to mention that the content should be plain text.

[benjaminleonard]

Thanks for the feedback! Added the links object and test that checks that the external links are accessible – I could pull that out into its own PR if that's helpful.

Its become a bit of a mishmash because I've changed helpText -> description and description to tooltipText as discussed. That can also be picked into its own PR to merge into this one.

[david-crespo]

I should put in a lint rule or something about this — I think the best practice is to avoid default exports. Bundlers don't like them, something like that. They don't really do anything useful anyway. For now you can also collapse this down, we don't need to distinguish external. I'd just do export const links = { cloudInitFormat: ... }.

[david-crespo]

Decided the fallback to GET is overkill since the 2 links we have both work with HEAD and it's possible other ones will for the foreseeable future.

[david-crespo]

I think we're good! Nice work!