Draft: Add key listing functionality, replace placeholder subcredentials with values from keystore

I'm opening this MR to get some early feedback on these APIs. The code is a bit rough around the edges, and it's missing some tests.

This adds some new keymgr APIs for listing keys (Keystore::list()), and for searching for keys that match a given pattern (KeyMgr::list_matching()).

Some important points to note:

• Note that the KeyMgr APIs don't support looking keys up by ArtiPath/CTorPath. To retrieve a key you currently need:

  • a dyn KeySpecifier that identifies the key¹
  • to know the concrete type of key you are retrieving (specified via the K type parameter)

• To use KeyMgr::list_matching(), you need to specify a KeyPathPatternSet, which contains 2 patterns: one for matching ArtiPaths, and one for CTorPaths. KeyMgr::list_matching() will return all the ArtiPaths/CTorPaths that match the specified patterns (if multiple keystores are configured, you will potentially get results from multiple backends). The caller is responsible for parsing the resulting ArtiPaths/CTorPaths and constructing the dyn KeySpecifiers that can then be used to look up keys.

• I've decided against making ArtiPath itself optionally contain wildcards because:

  • Making ArtiPath optionally contain wildcards means changing all keymgr APIs to return/accept multiple keys rather than just one (e.g. get() will return Vec<K> rather than just K, etc.). However, most of the time you want to retrieve/remove/insert a single key, so changing the API this way would make the KeyMgr overall less ergonomic
  • Even if we provide a separate get_matching APIs for batch retrieval, it still wouldn't work very well, because the wildcards would allow you to select multiple keys, of potentially different types, and the type system doesn't allow us to return an arbitrary number of keys of arbitrary types (KeyMgr::get wants to know the type K of the key being retrieved). That being said, we can provide a remove_matching API.

• the list_matching API returns the capture groups of the pattern being matched. These are needed for parsing ArtiPaths/CTorPaths as HsSvcKeySpecifiers. The resulting TryFroms for HsSvcKeySpecifier are pretty ugly -- maybe we need a fundamentally different approach here?

I've also tried to address the TODO HSS BLOCKER in ipt_establish.rs using these new APIs. See d45630d4

---

1. KeySpecifier really just specifies the ArtiPath and/or CTorPath of the key, so technically we could adapt these APIs to work with ArtiPath/CTorPaths, but that would involve rethinking some of the ArtiNativeKeystore logic, as it currently quite strongly assumes KeySpecifier::arti_path() will return a valid path. We could, for example, implement KeySpecifier for ArtiPath and CTorPath, and make both KeySpecifier::arti_path() and KeySpecifier::ctor_path() return a Result/Option. But then we will need to give KeyMgr some sort of way of deciding whether the requested dyn KeySpecifier can be used with any of its dyn Keystores (e.g. if we impl KeySpecifier for CTorPath, we can't use this specifier with ArtiNativeKeyStore as its arti_path impl will return an Err) ↩