feat: [M3-8005] – Add disk_encryption to types & validation schemas

[dwiley-akamai]

Description 📝

Add disk_encryption to types & validation schemas as appropriate based on the API spec (see ticket for link)

Changes 🔄

• EncryptionStatus type added; disk_encryption field added to Linode, Disk, CreateLinodeRequest, and RebuildRequest interfaces
• disk_encryption added to CreateLinodeSchema and RebuildLinodeSchema; it is nullable and optional, but if provided should have a value of either "enabled" or "disabled"

Note

@TODO LDE: remove optionality once LDE is fully rolled out was added as a comment to a few new properties. These are instances where, when LDE is fully rolled out, disk_encryption will always be included on that object. I think marking them as optional at this point is fair because not doing so would be premature, and also likely confuse consumers of the JS Client.

Target release date 🗓️

5/13/24

How to test 🧪

Verification steps

• Ensure that Create Linode and Rebuild Linode functionality have not been adversely impacted (should still go through as expected with no errors related to the the disk_encryption field)
• Confirm the changes align with the API spec

As an Author I have considered 🤔

• 👀 Doing a self review
• ❔ Our contribution guidelines
• 🤏 Splitting feature into small PRs
• ➕ Adding a changeset
• 🧪 Providing/Improving test coverage
• 🔐 Removing all sensitive information from the code and PR description
• 🚩 Using a feature flag to protect the release
• 👣 Providing comprehensive reproduction steps
• 📑 Providing or updating our documentation
• 🕛 Scheduling a pair reviewing session
• 📱 Providing mobile support
• ♿ Providing accessibility support

[bnussman-akamai]

Is there a justification for using enabled | disabled as compared to a boolean? It kind of breaks the Boolean pattern like private_ip, backups_enabled in the Linode Create payload

[dwiley-akamai]

Is there a justification for using enabled | disabled as compared to a boolean? It kind of breaks the Boolean pattern like private_ip, backups_enabled in the Linode Create payload

I can't go into much detail here (see page 6 of the spec for more in-depth discussion on it by members of the API team), but essentially it has to do with future-proofing.

[github-actions]

Coverage Report: ✅
Base Coverage: 81.82%
Current Coverage: 81.82%