This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and Host classes.
I wonder if this class should actually be in Host. While some specific implementation of it might be host-dependent, the interface itself is not. I kind of envision at some point in the future having a target that contains all of our core interfaces that someone can include and re-implement small pieces of the debugger without having to bring in the entire thing. This is also nice from a mocking / unittesting perspective.
So I think this would be better if it were in Utility (or some other top-level library such as Interfaces)