When Perforce looks up repository information, it fails to account for

SSL variations for repositories (those with a ssl: prefix). This

prevents some types of repositories from being found if performing a

scan based on paths, rather than a direct name lookup.
Now, the computed repository information factors in "Broker encryption"

and "Server encryption" fields, and uses those to include

ssl:-prefixed repository paths in the list of paths to check. These

are chosen as a priority over non-SSL paths.
As part of this, the logic for computing this information has been

reordered and cleaned up. We now look up (and bail early on) the easy

stuff, and save the more expensive stuff (hostname alias resolution) to

the end.
The hostname alias resolution has also been simplified. If there's an

issue looking up aliases, we no longer bail early from building up a

list of hostname candidates. Instead, we only avoid adding aliases to

the list. This is mostly useful for unit tests, but also helps keep the

list of possible Perforce repositories consistent even when alias

resolution fails.

Unit tests passed.
Tested with a local server deployment. Verified it was adding ssl:

prefixes as possibilities when seeing Broker encryption: encrypted

or Server encryption: encrypted fields in p4 info.