[Auditbeat] Cherry-pick #9327 to 6.x: Login metricset

[cwurm]

Cherry-pick of PR #9327 to 6.x branch. Original message:

This adds the login metricset to the Auditbeat system module. It's the last of the six initial metricsets. It only works on Linux, and detects not just user logins and logouts, but also system boots and shutdowns.

It works by reading the /var/log/wtmp and /var/log/btmp file (and rotated files) present on Linux systems. In reading a file, it is similar to Filebeat, except that UTMP is a binary format, so reading happens using a binary Go reader. See utmp(5) for the format of that file.

The logic is roughly as follows:

1. The config parameters login.utmp_file_pattern and login.btmp_file_pattern will contain the pattern matching the wtmp (good logins, as well as system shutdowns and boots) and btmp (bad/failed logins) files and rotated files (if desired). The defaults are /var/log/wtmp* and /var/log/btmp*. These are expanded using filepath.Glob and the files are sorted lexicographically in reverse order (i.e. /var/log/wtmp.1 will come before /var/log/wtmp) so that we read older login records first - reading in order is required for matching login and logout records, see next steps.
2. Every Fetch it checks for new entries: Any new files are read from the beginning, while known files are read from a saved offset. To that purpose, the last offset per file is saved and persisted to disk in beat.db. A new file is one that has an unknown inode, but files are also read completely if their newSize < oldSize for some reason (that should make it work with any potential inode reuse - very unlikely since this will never read a lot of files but still possible).
3. New UTMP records are converted to events (LoginRecord in the code). Boot and shutdown events are fairly straightforward, user login and logout events have to be matched using their tty- so there is a loginSessions map that stores logins to enrich the logouts, and is also persisted to disk.

Note: This dataset also introduces event.origin containing the file the event came from, e.g. /var/log/wtmp.1. In other cases, it would be something like procfs or netlink. It's useful to know where information comes from, e.g. to know how reliable it is.

[elasticmachine]

Pinging @elastic/secops

[cwurm]

I pushed two changes:

1. Field definition for event.outcome since 6.x does not have all ECS fields.
2. Fix for a bug that sneaked in: event.type was still used instead of event.kind. I'll open a quick PR to fix it in master as well.

[webmat]

LGTM