fix LVM2 creation_time > DateTime.MaxValue - #48

Note: I've scheduled a rebuild. Nuget timed out.

@zivillian what is the exact value of the LVM2 volume in Bitdefenders case?

I've attached the raw metadata as read from the disk:
metadata.txt

The relevant part part was already quoted in the initial description.

Those are completely insane times. I'm looking at my own LVM setup currently, and as seen by lvmdump, I have times like:

			creation_time = 1484343074	# 2017-01-13 22:31:14 +0100
			creation_time = 1484343076	# 2017-01-13 22:31:16 +0100
			creation_time = 1484343082	# 2017-01-13 22:31:22 +0100

Would it be possible for you to double check, and run lvs or similar on the gravity zone host, to check if LVM's own tools are failing with this?

Sidenote: The LVM header is all text .. ? .. Damn.. Let's hope it's always newline seperated...

I don't have the credentials for this image, but I've attached the disk to an ubuntu 16.04 host and ran vgcfgbackup. This replaced one of the two timestamps by Int64.MaxValue. I guess, that the lvm was created by a broken version, but I wasn't able to find a specific patch or fix at the lvm2 repository.
ubuntu1604.txt

I've been reading some of the LVM2 tools code, and from what I gather, they'll just use the invalid time as is. They'll read it into an uint64, and then write it back out as is.

If they ever use it for display, they'll get stuff like (null).

Example C code:

#include <stdio.h>
#include <time.h>
#include <stdint.h>

int main ()
{
   uint64_t curtime = 9223372036854775807;

   printf("Current time = %s", ctime(&curtime));

   return(0);
}

It prints: Current time = (null)