refactor(api): Disallow direct access to .state through Protocol Engine state views

[SyntaxColoring]

Overview

A trivial refactor to avoid directly accessing private implementation details.

Details

In opentrons.protocol_engine.state, in a FooStore+FooView+FooState triad, we generally want to treat FooState as a private implementation detail of FooStore+FooView. For example, we don't want command implementations to access it, and we especially don't want Python-Protocol-API–level code to access it. One reason is encapsulation, and another reason is to prevent that code from mutating FooState, which would be unsafe.

However, it looks like we have been exposing FooState through an inherited FooView.state property. A handful of command implementations and Python Protocol API bits were using it. I think this was accidental? It was certainly surprising to me.

This replaces those FooView.state accesses with public FooView methods and removes access to FooView.state.

Test Plan and Hands on Testing

None needed.

Review requests

Is this what we want?

Risk assessment

Low.

[sfoster1]

Looks good, but why remove that HasState?

[SyntaxColoring]

why remove that HasState?

That's what was exposing the state. HasState defines a state @property, and each view was inheriting it from there.