Joshc slac/reset ioc by tree

[joshc-slac]

Description and Motivation and Context

A feature that was requested by scientists was the ability to reset IOCs by tree. This inspired the advent of utility_trees. Utility trees differ from idioms in this way: idioms specify a tree structure utility trees are a specific instantiation of a tree structure. This allows tree functionality specific process variables be stored within the object representing the utility tree. This is present in the "reset ioc" utility tree in the cached hbeat_val representing the runtime polled heartbeat value of the ioc due to be reset such that we can ensure on reset the value is less than the original.

The tree structure takes the form of "get hbeat val then perform check and do to confirm reset of hbeat value. The check and do is of form SetPV and sets the SysReset pv. And a final action which resets the cached heartbeat to negative 1 such that future cache's will be successful.

Note for future development:

All of this strongly motivates another type of non persistent action node. Josh's initial operational speccing on needing all action nodes to be persistent was over-zealous. We can and should design an async or spawnable & joinable action node as well...

How Has This Been Tested?

caproto IOCs don't natively seem to mock this "reset ioc by PV" interface, though there are some references to it in documentation but only if one actually uses caproto via procServ? So I just mocked the PVs within a mock_ioc that increments the hbeat count via the scan property.

Where Has This Been Documented?

Pre-merge checklist

• Code works interactively
• Code follows the style guide
• Code contains descriptive docstrings, including context and API
• New/changed functions and methods are covered in the test suite where possible
• Test suite passes locally
• Test suite passes on GitHub Actions
• Ran docs/pre-release-notes.sh and created a pre-release documentation page
• Pre-release docs include context, functional descriptions, and contributors as appropriate