Conflicts:
	lib/puppet/feature/base.rb
	lib/puppet/file_serving/configuration.rb
	spec/unit/indirector/ssl_file_spec.rb
	spec/unit/parser/functions/extlookup_spec.rb
	spec/unit/resource/catalog_spec.rb
	test/language/ast/variable.rb

Ticket/2.7.x/8662 root on windows

When running as root, puppet will by default manage internal file
permissions for file-related settings. However, ruby does not support
chown/chgrp functionality on Windows, so puppet will fail to run
(puppet apply generates an exception while trying to set the owner,
etc).

This commit disables internal file permissions handling on Windows
until we add support for chown (at least) as part of the larger file
type effort on Windows.

When running as root, puppet will generate a catalog from its settings
to create the various directories, e.g. var, ssl. If mkusers is true
and a setting implements owner and/or group methods, then puppet will
automatically add user and group resources to the catalog (provided
the user name is not root and the group names are not root or
wheel). This functionality will not be supported on Windows, and so
this step is skipped.

This commit changes Puppet::Util::SUIDManager.root? (and
Puppet.features.root?) to only return true if the user is running with
elevated privileges (granted via UAC). If this check fails because
elevated privileges are not supported, e.g. pre-Vista, then we fall
back to checking if the user is a member of the builtin Administrators
group.

This means if you are logged in as Administrator on 2008,
Puppet.features.root? will return false, unless you are explicitly
running puppet as an administrator, e.g.

 runas /user:Administrator "puppet apply manifest.pp"

This commit also adds tests to ensure SUIDManager.asuser is a no-op on
Windows, since Windows does not (easily) support switching user
contexts without providing a password.

The root feature was being evaluated prior to the microsoft_windows
feature being defined. On Windows, this had the side-effect of calling
Process.uid prior to the win32 sys/admin gem being loaded. And the
default ruby implementation of Process.uid always returns 0, which
caused Puppet.features.root? to always return true.

This commit reorders the syslog, posix, microsoft_windows, and root
features due to dependencies among them. This ensures the
microsoft_windows feature is defined prior to evaluating the root
feature.

As a result of this commit, the SUIDManager now calls the win32
sys/admin version of the Process.uid method, which returns the RID
component of the user's SID. As this is not 0, Puppet.features.root?
will now always return false on Windows. A future commit will fix
this, so that Puppet.feature.root? only returns true when running as
the Windows-equivalent of root.

These methods aren't available until Ruby 1.8.6 (Dir.mktmpdir) and Ruby 1.8.7
(Object#tap).

Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 61df3f7c39d74b82e37f48c3519293406036e1e9)

FileSetting#to_resource had a provision to not attempt to manage files in /dev,
which effectively stopped spec from trying to make their configuration
directories in /dev/null. However, on Windows, the path turns into something
like C:/dev/null, so the specs were still trying to manage their configuration
directories when this wasn't desired or handled by the spec.

Now, we also exclude management of C:/dev (or similar), to mimic the behavior
on Windows. Because this isn't a standard path (and thus will not be used for
anything else), there seems to be no harm in treating it as though it were
really /dev.

Reviewed-By: Josh Cooper <josh@puppetlabs.com>
(cherry picked from commit 44719fcf9f9053a7be1bea59d516f24d2234ede4)

Added missing spec tests for Windows service provider methods:
  :stop, :enable, :disable, and :manual_start
Refactored to match Nick's previous work.

Reviewed By: Nick Lewis [nick@puppetlabs.com]
(cherry picked from commit d08ae7fd2180c95d1fcafa149128d25cc4680c6c)