feat(robot-server): add protocol_kind to the protocols endpoint and persistance layer.

[vegano1]

Overview

A "Quick Transfer" protocol is a protocol that is generated by the on-device-display (ODD) (For now), to perform routine plate filler actions without needing to use a computer and the desktop app. This is a mostly client-side driven feature, However, we do need to make changes on the backend to support this feature. We primarily want 20 Protocol slots intended for "Quick Transfer" protocols. So we need to tell which type of protocol we are dealing with, so we can limit their count, migrate them, store them in the database, etc.

This pull request sets up the backend to handle "ProtocolKinds" sent as "protocolKind" Form data key in the POST /protocols endpoint. We then add this new key to the rest of the infrastructure required to consume this new key, persist, and get reported. This will let us mark protocols as "standard" or "quick_transfer" for the robot server to perform side effects on specific protocol kinds, like not storing runs for "Quick Transfer" protocols.

Closes: PLAT-311 PLAT-312 PLAT-313 PLAT-315 PLAT-316

Test Plan

• Make sure that a robot can start up properly after migration
• Make sure adding the "protocolKind" form data key to the POST /protocols endpoint returns the correct kind of protocol
• Make sure that the GET /protocol endpoint returns the correct protocolKind value
• Make sure that protocol_kind persists through the robot server app restarts.

Changelog

• Add the "protocolKind" form data key to the POST /protocols endpoint
• Add "protocolKind" to the ProtocolResource class
• Add "protocolKind" to the Protocol class
• Add the protocol_kind key to the database under schema 5
• Add a schema v4_v5 migration

Review requests

• Make sure this makes sense and that I'm not overlooking anything too critical

Risk assessment

• Medium, this alters the database requiring a migration

[CaseyBatten]

Looks good overall, as discussed in person if we change out the query on the POST /protocols request to a form instead this will be in line with the rest of our HTTP API decisions so far. All other decisions seem sensible, your call regarding the exclusion of the ProtocolKind type on the Protocol constructor.

[sanni-t]

Looks good! Thank you for making all the changes!
Good to merge once tests pass