Y24-190: Support Limber with Qcable on API v2

[sdjmchattie]

Closes #4615

Changes proposed in this pull request

• Add functionality to support the use of Qcable over API v2 for Limber.
• Update tests for Qcables.

Instructions for Reviewers

[All PRs] - Confirm PR template filled
[Feature Branches] - Review code

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.37%. Comparing base (3d45f75) to head (b64b85f).

Additional details and impacted files

@@                 Coverage Diff                 @@
##           develop-Y24-190    #4569      +/-   ##
===================================================
- Coverage            89.26%   86.37%   -2.90%     
===================================================
  Files                 1405     1405              
  Lines                29965    29967       +2     
===================================================
- Hits                 26749    25883     -866     
- Misses                3216     4084     +868     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yoldas]

Migrates to Qcable to V2 API.

• Handles gradual transition from asset terminology to labware; side-by-side use and deprecation warnings.
• Includes matching relationships from V1 API, namely labware and lot resources.
• Complete barcode filtering is implemented.
• Restrictions are in place to prevent direct modifications.

QcableCreator relationship is missing on the Qcable resource but I don't see it as a problem. It is relevant only to creation of Qcables. If you look at how Qcables are created in GateKeeper, you will see that API V1 qcable_creator end point is called to create them. Another example is the creation of MBrave tag plates in Sequencescape (rake task), again they are created through QcableCreator. Simply creation of a QcableCreator has an after trigger in Sequencescape to make_qcables. It looks like the API V1 was forced to represent the operation as a resource and also disallowed direct creation of individual Qcables.

I can't quite understand how we support for example the Qcable creation via user, lot, and count arguments in V2. In other words, how do we support operations like qcable_creator or state_change of V1 in V2?

I am approving this PR because it is a proper migration of the Qcable resource itself to V2.