BIT-100: Adds the known device API call

[nathan-livefront]

🎟️ Tracking

BIT-100

🚧 Type of change

• 🚀 New feature development

📔 Objective

This PR adds the Known Device API call and related models.

The API call isn't hooked up to anything yet, since there isn't any UI for the login flow yet, but once the UI is added we'll be able to use this API call.

📋 Code changes

• KnownDevice: Added related models to support making the /devices/knowndevice API call, including request and response definitions.
• DeviceAPIService.swift: Added the API call for /devices/knowndevice

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[bitwarden-bot]

Checkmarx One – Scan Summary & Details – 7cd6349e-0aac-4f69-8642-61c425976f92

No New Or Fixed Issues Found

[github-actions]

	1 Warning
⚠️	Total coverage less than 80%

Code coverage

Total coverage: 48.61%

Powered by Slather

Generated by 🚫 Danger

[matt-livefront]

Nice!

[fedemkr]

Great work!
🤔 A small question about the Fixtures: Could we have like "generic" fixtures when using a unique value, as Bool in this case. So instead of having KnownDeviceFalse.json and KnownDeviceTrue.json, we could have False.json and True.json so they can be reused avoiding potentially having multiple files with the same content for trivial data. Furthermore, is there an advantage on having files created for these trivial data for fixtures? We could directly create it without the files.
Additionally, if all/most of the fixtures files are going to be JSON, could we have a func loadFromJsonBundle(resource: String) -> APITestData to avoid hardcoding the json extension on each call?
What do you think?

[nathan-livefront]

🤔 A small question about the Fixtures: Could we have like "generic" fixtures when using a unique value, as Bool in this case. So instead of having KnownDeviceFalse.json and KnownDeviceTrue.json, we could have False.json and True.json so they can be reused avoiding potentially having multiple files with the same content for trivial data.

I'm on board with having generic fixtures for data like this! That makes a lot of sense. But (as I address below), I think I'll remove these files in favor of creating the fixtures in code instead.

Furthermore, is there an advantage on having files created for these trivial data for fixtures? We could directly create it without the files.

My intention was to follow the same convention that will be used for all other fixtures that we will be using for unit testing our API calls. That way all the fixtures that are available in APITestData extensions would have their own files to go along with them. However, I also see the argument about keeping trivial files like this out of the project, so as to eliminate clutter. I'll remove the files and hardcode the fixtures instead!

Additionally, if all/most of the fixtures files are going to be JSON, could we have a func loadFromJsonBundle(resource: String) -> APITestData to avoid hardcoding the json extension on each call?

Love this, I'll add a method for doing this.