Time-Drift issue resolved - Output-Naming-Scheme enhanced

[arashdalir]

Improvements:

1. Time-drift issue is resolved:
   • Because the timer used in system wasn't exact, the application captured more than the "duration:n" seconds in each file (around 30ms per file with duration:60). This resulted in a drift in capture-timestamps ~ every 3 hours, meaning the first captured packet at 03:00 would have been actually captured at 03:00:01 (assuming capturing begun at 00:00:00). As a consequence, the applications that process data periodically, will have time-drifts on a daily basis.
   • The solution was to check the time-difference between the last-expected-packet and the last-captured-packet, and as soon as the difference is more than duration:n-seconds, stop the current interval and start a new one.
2. A new argument (-s) allows users to stop capturing after one interval (based on -n duration -n packets). If this options is selected, the interval_counter will not be appended to user-defined filename.
3. File-naming-schema enhanced:

• If the -o option is not defined, the default naming scheme is selected: (user-defined-name)_[(interval-counter)]
• In order to allow an output-naming-schema similar to the that of wireshark, the system now allows its users to add utc/local timestamps at the end of their selected filenames. Using -o utc=yes|no, a user can define, if the capture-begin-timestamp formatted as YYYYMMDDHHMMSS shall be added at the end of each file name. If ring-buffer mode is selected, the capture-interval-counter is prepended to this value. The general file-output-name looks like (user-defined-name)[(interval-counter)][(timestamp)]

Notice:

Unfortunately the indent in the save_to_pcap was changed, therefore GitHub marks many lines as modified, although they are technically the same. If that is a problem, we will try to rectify this matter and create a new request.