Investigation into Engine, Pool, Filesystem, and BlockDev trait definitions

[jbaublitz]

Currently, we use trait objects to unify the return types between the sim and strat engine. Trait objects are causing problems for per-pool locking due to them being unsized, they incur a performance penalty, and I'd like to propose switching to type parameters and associated types.

@mulkieran brought up the concern of monomorphization and bloat of our binary size. Due to this, we'd like to explore the following steps:

• Change from trait objects to type parameters and associated types
• Compile out the sim engine in the release build
• Check the binary size using trait objects and compare it against the release build using type parameters.

[jbaublitz]

@mulkieran We may not need to compile out the sim engine after all. The size with trait objects is 97M while without them, it's 108M. While that is an increase, it's not nearly as large as I was expecting. It may be desirable to do it anyway, but the main thing to think about here is whether there's value in including the sim engine in the release build simply for D-Bus API configuration testing. Let me know what you think!