Update smf.py to fix availability check on SmartOS

Checking availability uses the services name, not the package name. The get_all function (which is used by available and missing functions) returns the service name. While to install the package, you need the package name. For example, for nginx, you have pkgsrc/nginx for the service name and nginx for the package name.

/usr/bin/svcs -H -o SVC <packagename> will take the package name and return abbreviated service name which can then be compared against the service list returned by the get_all function.

This fix works on SmartOS, but it was not compared to other SMF distributions. Therefore, the fix was confined to SmartOS.
Fixed the trailing whitespace.
Use svcs for service.available in Solaris. Allows use of partial FMRI
match. Addition to #13983.
smf.py: use FMRI instead of SVC in Solaris svcs commands
Cherry-pick #14022 and #14156 onto 2014.1 branch
smf support cleanup

If it works on SmartOS and it works on Solaris, it's just plain the
right way to do things.
Remove the if statement.
Merge pull request #14305 from nshalman/smf-backport-14022-and-14156

Backport  #14022 and #14156 onto the 2014.1 branch
Clean any stale dir before creation
Randomize salt cloud deployment directory
Correct path
Remove unusued testing code
Correct perms for ps module
Use local bootstrap
reqver uses a tuple not a string anymore
Merge pull request #14478 from UtahDave/2014.1

reqver uses a tuple not a string anymore
Ensure correct perms after dir creation
update documentation about SmartOS esky packaging
smartos esky: improve "installer"

detect if this is a global or non-global zone
global zones are always minions

if the user passes in the name/address of the master
we configure a minimal minion file and launch the minion
SmartOS: run salt minion in an audit context

This fixes an issue @njones11 was having with
multiple cron.present states.

"crontab -l <username>" would fail, so the temp file
would be empty, a given cronjob would go in
and then the "su - <username> crontab <temp file>" would
succeed.

This evaded debugging attempts because if you invoked the salt
minion manually from a login shell, an audit context would
already exist and the "crontab -l <username>" would succeed.

The hint was a message in the debug log of:
[ERROR   ] Command 'crontab -l legion' failed with return code: 1
[ERROR   ] stderr: crontab: The audit context for your shell has not
been set.

We explicitly set up an audit context when launching the salt minion
which allows "crontab -l <username>" to succeed.

This may fix other issues and something similar
should perhaps be applied to pkg/smartos/salt-minion.xml

"5417" was chosen arbitrarily
Merge pull request #14501 from nshalman/esky-fixes-2014.1

backport smartos esky improvments to 2014.1