Add static memory cache for discovered resources

[SteveL-MSFT]

PR Summary

When using adapted resources, the engine will dynamically generate a nested configuration. Each configuration (outer and inner) would incur the cost of performing discovery. This change makes command discovery retain an in-memory static cache so that any multiple discoveries will just use the previous one.

[Copilot]

Pull Request Overview

This PR implements static memory caching for command discovery to avoid redundant discovery operations when using adapted resources. The engine previously performed discovery multiple times for nested configurations, which was inefficient.

Key changes:

• Adds a static cache module using global statics with mutexes for thread-safe access
• Refactors CommandDiscovery to use the cache instead of instance fields
• Replaces direct field access with cache getter/setter functions

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
dsc_lib/src/discovery/mod.rs	Adds the new cache module to the discovery module
dsc_lib/src/discovery/command_discovery_cache.rs	Implements the static cache with thread-safe global storage for discovered resources
dsc_lib/src/discovery/command_discovery.rs	Refactors CommandDiscovery to use the static cache instead of instance fields

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[andyleejordan]

Some questions, and some Rust I need to go look up.

[andyleejordan]

Oh I forgot to approve this.

[SteveL-MSFT]

@andyleejordan FYI - the mutex with macros was resulting in a deadlock, changing to using RwLock which is better anyways since don't need to mutate every time fixes this

[andyleejordan]

@andyleejordan FYI - the mutex with macros was resulting in a deadlock, changing to using RwLock which is better anyways since don't need to mutate every time fixes this

I'm curious where exactly the deadlock was. If it didn't deadlock in the same way with the wrappers, that indicates we're acquiring the lock in the same scope in some place where we meant not to hold the lock (and so were implicitly depending on the lock expiring inside the wrapper)...ah, probably where we're reading to check is_empty() or clone() it and then writing to it with extend()...so was it here?

fn discover()
...
        match kind {
            DiscoveryKind::Resource => {
...
// clone and then extend deadlocking?

If that's the case, then I agree, RwLock is the correct type to use given the usage.