Correct generated schema for Reference types

[tpoliaw]

I think this resolves the plan schemas returned from the plans endpoint. Do we
want to include some field in the schema to mark that the field should be a
reference rather than the value itself?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.06%. Comparing base (1cc2b8a) to head (46598b0).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #522   +/-   ##
=======================================
  Coverage   91.06%   91.06%           
=======================================
  Files          40       40           
  Lines        1779     1779           
=======================================
  Hits         1620     1620           
  Misses        159      159           

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

[tpoliaw]

Should the type value change as well? The <class 'bluesky.protocols.Readable'> form is not that useful - would it be better as bluesky.protocols.Readable?

[callumforrester]

LGTM, thanks!

Do we
want to include some field in the schema to mark that the field should be a
reference rather than the value itself?

Possibly, but let's do that in another PR, could also be done as part of #518

[DiamondJoseph]

We can infer it from whether the type is a known type or otherwise referenced in the schema.

Any time we have as a plan parameter a BaseModel/Dataclass/TypedDict, I think the generated schema will include $ref and the full definition of that type (although we should check). Would we ever be passing in something that is not either a default JSON type, a BaseModel/Dataclass/TypedDict or a device reference?

[DiamondJoseph]

Opened #523 to support the case of references nested inside structure, and having tested that TypedDict (and likely others) correctly get a $ref and defined subschema, this should allow us to handle #134