feat(api): Add robot context API skeleton

[Laura-Danielle]

Overview

Initial PR to create a skeleton API which exposes certain methods of a versioned HW api for finer robot control.

Test Plan

• Verify that a protocol which uses ctx._hw_manager still works as expected

Changelog

• Add a skeleton robot context

Review requests

Check that you're OK with how we access this API using python.

Risk assessment

Should be low-medium as we just changed how the underlying hardware is working as expected.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.70%. Comparing base (0a4b774) to head (4c29e21).

Additional details and impacted files

@@           Coverage Diff           @@
##             edge   #15745   +/-   ##
=======================================
  Coverage   63.70%   63.70%           
=======================================
  Files         300      300           
  Lines       15649    15649           
=======================================
  Hits         9969     9969           
  Misses       5680     5680           

Flag	Coverage Δ
g-code-testing	92.43% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[github-actions]

A PR has been opened to address analyses snapshot changes. Please review the changes here: https://github.com/Opentrons/opentrons/pull/

[DerekMaggio]

There is a class called RobotContextTracker that is part of performance-metrics.

If this feature makes more sense to call RobotContext than performance-metrics, the class in performance-metrics should get changed. I was instantly confused that you were using the performance-metrics class. Until I realized you werent.

If performance-metrics should be changed just let me know and I can handle it

[sfoster1]

I think the signature of move_to is wrong and also we might want to pull out the reiteration of the function name in the NotImplementedErrors since we'll just have to keep them up to date until merge.

[Laura-Danielle]

There is a class called RobotContextTracker that is part of performance-metrics.

If this feature makes more sense to call RobotContext than performance-metrics, the class in performance-metrics should get changed. I was instantly confused that you were using the performance-metrics class. Until I realized you werent.

If performance-metrics should be changed just let me know and I can handle it

Hey @DerekMaggio yes I think we definitely want to call this the RobotContext.

[DerekMaggio]

@Laura-Danielle, ticketed here

[ecormany]

Thanks for giving me a preview of this! We do need to make sure that docs builds succeed before merging to edge — see inline comment. All my other comments are wordsmithing that can be addressed now or later.

[SyntaxColoring]

What stability guarantees are we making about this robot context stuff? Is it the same as the "normal" Python Protocol API, where we preserve backwards compatibility and it's governed by apiLevel?

If so, I think we should not use anything from hw_types, or anything defined outside opentrons.protocol_api, in our public signatures. I can elaborate on this if needed, but going forward, I think we need to draw a really bright line between what is publicly importable and usable, and what is not.

But that doesn't apply if you're intentionally leaving these new APIs loose, raw, and non-guaranteed.

What do you think?

[sfoster1]

This has the same stability guarantees as the rest of the API, so you are correct, and we should not use anything defined outside opentrons.protocol_api.

[Laura-Danielle]

Agree with you both. Will address the better types in the implementation PRs.

[sfoster1]

This looks good to me at this point!

Got approval.