connect port and filter table

[arlimus]

(1) Adds style handling to filter table + optimizes its internals. It's the equivalent of:

resource.entries.flatten.uniq.compact

and can be used by:

filter.add(:field, style: :simple)

(2) Puts filter table into port. A forgettable internal change, if it weren't for:

port.where { protocol =~ /tcp/ && port > 80 }.listening?

(becomes especially useful if you want all listening ports on the node and then do some action on those, e.g.

port.protocols(/tcp/).entries.each do |socket|
  describe ssl(port: socket.port).protocols('ssl2') do
    it { should_not be_enabled }
  end
end

)

[chris-rock]

Awesome work @arlimus. It works as expected:

inspec> port.pids
=> [710, 39533, 40899]
inspec> port(3000).pids
=> [40899]
inspec> port(3001).pids
=> []
inspec> port(3001).processes
=> []
inspec> port(3000).processes
=> ["node"]
inspec> port(3000).protocols
=> ["tcp"]

I just found small issue, where entries is not returning the expected value for listening

inspec> port.protocols(/tcp/).entries
=> [#<struct  port=3000, address="0.0.0.0", protocol="tcp", process="node", pid=40899, listening?=nil>]

We need to adapt the new_entry method and call blocks? Lets do that in another PR, since this is further improvement and only an optimization for the inspec shell

[arlimus]

@chris-rock oh that's right, single entries don't have a functioning listening?. It actually opens an interesting case in filter-table, where aggregate operations on a list of entries are possible (e.g. listening?, enabled?, ...) but aren't being implemented for single entries. We can treat is as an issue in filter-table, which delegates these calls to each entry, without adding an implementation. It's a left-over from the regular .add(:field) calls.