WMI queries do not have a timeout by default and can subsequently hang.
This commit adds timeouts to avoid these hangs.
On timeout, `Get` will throw a `ManagementException` that has an error
code of `ManagementStatus.Timedout`. In the case of abstract storage,
this exception will be silently swallowed and the statistics from WMI
not updated until the next update interval, which seems appropriate.
The storage group, on the other hand, a timeout there would cause an
initialization exception which would be propagated up to the caller
(which seems ok as something must be terribly wrong for that WMI query
to fail).
The code was also updated to call dispose for all the WMI objects. I
don't see this causing a behavior difference, but I found it better to
be safe than sorry.
The timeouts were chosen to be a compromise between returning in a
reasonable timeframe and allowing WMI, which can be terribly slow, to
return the query.
There is no entry for `CopyMemory` exported from kernel32.dll as it is
omitted from the following output:
```
dumpbin /exports C:\Windows\System32\kernel32.dll
```
The name we're looking for is `RtlCopyMemory`. This does not affect
traditional .NET framework users as `CopyMemory` was special cased prior
to .NET core
([source](https://github.com/dotnet/runtime/issues/12496#issuecomment-483442084))
The incorrect entry point will cause an `EntryPointNotFoundException`
for NET core users (ref:
https://github.com/nickbabcock/OhmGraphite/issues/214)
There were a couple other entries in kernel32 that are missing:
- CreateFile
- LoadLibrary
Both functions appear to have a `CreateFileA` and `LoadLibraryA`
variant, but I do not know if those are appropriate.
PhyxionNL