ENH: Implement snapshot saving

[shilorigins]

Description

• Implement Snapshot saving (closes Implement saving a Snapshot #32 )
  • include helper methods Client._build_snapshot and Client._gather_pvs
• Extend Client._gather_data to accept any type of Entry, and make iterative rather than recursive

Motivation and Context

Client.snap itself is simple: it gathers all of the PVs in an entry, adds in the meta PVs, asynchronously fetches data for each PV, and then builds the snapshot. This method is named snap because save is currently used for the method that writes entries to the backend.

Since we want a function to gather all of the PVs from an entry, I decided to avoid code duplication by adding that functionality to Client._gather_data. This extension needed some messy code to handle all of the parameter permutations, which I was able to simplify by changing the method to be iterative. I also use hasattr rather than type checks to avoid length conditionals. I included Client._gather_pvs as a convenience method.

Fetching the data is straightforward due to ControlLayer._get_list.

Building the snapshot uses a simple depth-first process.

Alternative Designs

One major alternative was to have each Entry subclass implement method to gather its PVs. This conflicts with the current system because the entry classes don't have access to the backend to process UUIDs.

How Has This Been Tested?

New and updated tests in test_client.py

Where Has This Been Documented?

This PR, docstrings

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

[tangkong]

Some more thoughts. I think we need to think about how we handle meta_pvs, because at the very least, they are never initialized / configured in our current framework.

[tangkong]

I'm realizing now that we're defining meta PVs as a class variable, which prevents us from properly representing capturing changes to the meta_pv list. More concretely, if we:

• define one collection expecting a set of meta_pvs
• change the (global) list of meta_pvs
• take a snapshot with that same old collection

The new snapshot will pull the new meta_pvs, and might inadvertently be missing / duplicate PVs. This could be the behavior we want, but I think we need to find a way to make it more obvious if we do. Alternately we record meta_pvs as an instance variable (not class variable), and fill it with the global configuration on creation.

We also need to determine how we capture this in the Filestore backend, as currently this won't be recorded properly. This probably needs to be a separate dictionary / store external to the Root tree that gets stored

[tangkong]

This looks good to me. Let's get this in 👍