Improve automagic classes selection

[gcmoreira]

In the context of working with OS-agnostic plugins recently, I found that the automagic selection isn't working optimally.
For example, we can use the banners plugin, that is intended for Linux and Mac memory dumps which has only one requirement:

            requirements.TranslationLayerRequirement(
                name="primary", description="Memory layer to scan"
            )

In the current implementation of choose_automagic(), automagic classes are selected by identifying the OS from the plugin path (e.g., volatility3.plugins.linux.pslist is recognized as a Linux plugin). The function then filters classes based on the exclusion_list, resulting in a more refined selection of automagic classes.

Unfortunately, for OS-agnostic plugins, this function will return all automagics, see here. This means that for the banners plugin, it will end up executing all these:

construct_layers.ConstructionMagic
symbol_cache.SymbolCacheMagic
stacker.LayerStacker 
windows.WinSwapLayers
pdbscan.KernelPDBScanner
symbol_finder.SymbolFinder
linux.LinuxSymbolFinder
mac.MacSymbolFinder
module.KernelModule

As a result, the framework will attempt to detect the DTB, ASLR shifts, locate banners and match them with the ISFs,etc. for all OSes, despite these not being required for this plugin. The only automagic required in this case is the stacker.LayerStacker class.

I think it would be a good idea to redesign this code for a more precise selection of the automagics needed for each plugin, such as using the plugin requirements. This may require a more detailed requirement list, but it's something we should investigate further.

[ikelos]

Ok, happy to leave this open as a todo, but it feels fairly low priority. The automagic running just burns a bit of time and shy of requiring each and every plugin to list the automagics they want to run, I'm not sure how better to deal with it? We could make a special exception for plugins that only ask for a LayerRequiment rather than a ModuleRequirement, but that then forces all windows plugins to require finding a module, which may not always be what we want. So if there is a better way of doing it, that's still relatively easy to code up without needing each plugin to say what it needs then I'm game, but I won't lose sleep if we don't find it... 5:)