Initial SECoP support

[Tom-Willemsen]

A first pass at supporting the SECoP protocol using FastCS.

---

Implemented features:

• Supports both CA & PVA (& Tango, rest, GraphQL) transports, automatically creates attributes (PVs) with appropriate types
  • For details including supported datatypes in each transport, see docs
  • Can support multiple transports simultaneously (e.g. CA & PVA) - then the supported datatypes are the intersection of supported datatypes in each selected transport.
  • For EPICS PVA, PVI PVs are also created so that the IOC is self-describing
• All top-level SECoP datatypes are supported if they are representable in the underlying transport (CA/PVA/Tango).
  • But nested complex data types, e.g. array/struct/tuple/matrix inside array/struct/tuple are not supported - array/struct/tuple can only contain scalar types.
  • Commands are supported as long as both arguments and return values are either absent, or one of the supported data types
  • A fallback for unsupported datatypes is "raw mode", which exposes the transmitted JSON as a string.
    • This means that an accessible with an unsupported type can still be used, albeit with more difficulty (a client needs to construct the JSON themselves).
• A configurable set of "quirks" to get around limitations of transports, e.g.:
  • Truncate descriptions to 40 characters for EPICS CA
  • Read structs/tuples in raw mode as these can't be supported in EPICS CA
  • Skip problematic or unnecessary modules/accessibles entirely
• Reconnection after connection loss
• Auto-generated .bob (Phoebus) GUIs, although they do not look very good (this comes for free from FastCS)

SECoP features not implemented (for now):

• UDP discovery
• Websockets (could be added later - but needs a websocket connection type adding in FastCS first)
• Any handling of asynchronous updates (we send a deactivate message at startup; FastCS doesn't have infrastructure yet for async messages)
• check and logging extensions
• Any handling of error_* replies beyond logging and carrying on
• Any handling of timestamps or errors in a data report (these are discarded).
  • Handling timestamps may be possible in future with changes to FastCS.
• Any form of access control/visibility control except for the readOnly flag (which simply controls whether an AttrR or AttrRW is created)
• Any handling of "interface classes" - the raw accessibles are created, but interface classes are currently ignored.

---

Basic communication/functional tests have been done against:

• A lewis emulator, with extremely minimal functionality
• 'Gas flow' SECoP device to prove interoperability with other SECoP implementations.

However, I'd expect to have to 'tweak' things that have been missed in this initial implementation, as and when we get SECoP devices in real life, since this implementation is not extensively tested against all possible permutations of SECoP features.

[KathrynBaker]

I may have missed something, but this looks like a reasonable implementation, and the SECoP emulator looks like a good start to a more complete one in the end.