Experimental PowerShell discover extension

[Gijsreyn]

PR Summary

Implements an optimized approach to discovering PowerShell resources using .NET with parallel processing and direct result synchronization.

The previous approach using Get-ChildItem had unnecessary object overhead and required post-processing with Where-Object. The same is implied when using a thread-safe collection (ConcurrentBag), which adds unnecessary complexity.

PR Context

Fix #913

Note

While I recognize the need for caching in the issue, I left it out for now, assuming we can increment it over time.

[Gijsreyn]

With PR #1025 around, it might be worthwhile to rename the directories.

[michaeltlombardi]

A few questions and requests:

1. Do I correctly understand that this extension only for resources implemented in PowerShell and excluding Windows PowerShell? If so, do we need a second extension for discovering those resources, or can we handle that in this one? I'm not sure I see an immediate reason for why we can't handle both here, given the manifest has to indicate whether the resource is invoked with powershell or pwsh.
2. Can we slightly restructure this script to define (currently empty) param block and put the implementation into the process block? That can help with organization and testing later on.
3. The current implementation can't run in Windows PowerShell, I think, given the use of ForEach-Object -Parallel - but we can still discover resources in Windows PowerShell modules.

[Gijsreyn]

A few questions and requests:

1. Do I correctly understand that this extension only for resources implemented in PowerShell and excluding Windows PowerShell? If so, do we need a second extension for discovering those resources, or can we handle that in this one? I'm not sure I see an immediate reason for why we can't handle both here, given the manifest has to indicate whether the resource is invoked with powershell or pwsh.
2. Can we slightly restructure this script to define (currently empty) param block and put the implementation into the process block? That can help with organization and testing later on.
3. The current implementation can't run in Windows PowerShell, I think, given the use of ForEach-Object -Parallel - but we can still discover resources in Windows PowerShell modules.

1. The one currently written is only compatible with PowerShell 7+ because of the [System.IO.EnumerationOptions]. We might be able to rewrite it, but as you also mentioned (from point 3), the Foreach-Object -Parallel is not implemented. It would be best to create a second extension for it with different logic.
2. Sure, I'll implement this change. Thanks for the comment!
3. Answered in point 1.

[michaeltlombardi]

Are we throwing away paths with WindowsPowerShell in them for performance reasons or because we don't want to support discovering resources shipped in Windows PowerShell modules?

If the latter, I think we might be better off retrieving the folder paths for discovered modules and searching those.

[Gijsreyn]

Quite honestly, the only reason that I'm filtering it out is because if I can remember correctly, there was a bug in the past where we filtered out WindowsPowerShell in the adapter (or tests). Looking through the codebase, I can see this was the change: https://github.com/PowerShell/DSC/pull/777/files

If we opt for searching folder paths, I suppose it needs to match the specific operating systems, which becomes a ugly if/elseif/else block. It also limits custom installation, which will be lost. For example: