user resource should support filtertable

[ksubrama]

No description provided.

[chris-rock]

This PR introduces a new syntax for the user resource but still allows users to fallback to the old behavior.

New:

describe users.where(uid: 0).entries do
  it { should eq ['root'] }
  its('uids') { should eq [1234] }
  its('gids') { should eq [1234] }
end

Still works:

  describe user('root') do
    it { should_not exist }
    its ('uid') { should eq 0}
    its ('username') { should eq 'root'}
    its ('gid') { should eq 0}
    its ('home') { should eq '/root'}
    its ('shell') { should eq '/bin/bash'}
  end

The new syntax allows queries across multiple users. The single user resource is a very common special case that we will continue to support.

Integration test pass now for linux and OS X

TODOs:

• Ubuntu, Redhat, Suse
• OSX
• Windows
• Solaris
• AIX
• FreeBSD
• HPUX
• Performance optimizations for single user resource
• update unit tests

[chris-rock]

I'll talk with HPE for HPUX support later

[stevendanna]

Overall this looks good to me.

One thing that caught my eye is that on Linux, I believe it is the case that the users resource will parse /etc/passwd while user resource will shell out to commands. This could potentially be an issue for some users who have configured user databases in nsswitch other than the passwd file as the two resources will show different results. I think the behavior here is reasonable, just wanted to note the difference.

[chris-rock]

@stevendanna This is a good point. Currently the users resource only supports local users. That is something that should be documented properly. Same applies for Windows et al.

[chris-rock]

@stevendanna I added further comments to address that and make the behavior of the users resource more clear

[stevendanna]

👍

[chris-rock]

fixes #948