Fix "prefer downloaded" dive sample merging case

When we have a preferred dive computer that overrides old information
when merging two dives, we just copy the dive computer data over.
However, we need to clear the source of the dive computer data so that
we then don't free the sample data when that old source of the newly
merged dive gets free'd.

This fixes a memory scribble (and likely SIGSEGV) for the "prefer
downloaded" case.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add basic divecomputer info setup with xml parsing and saving

This also knows how to save and restore multiple dive computers in the
XML data, but there's no way to actually *create* that kind of
information yet (nor do we display it).  Tested by creating fake XML
files with multiple dive computers by hand so far.

The dive computer information right now contains (apart from the sample
and event data that we've always had):

 - the vendor and product name of the dive computer
 - the date of the dive according to the dive computer (so if you change
   the dive date manually, the dive computer date stays around)

Note that if the dive computer date matches the dive date, we won't
bother saving the redundant information in the XML file.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Match newly downloaded dives against dive computer information

Now that we have more complete dive computer information, we can use
that to match the dives we download, and stop with the hacky "Would we
merge this" check.

For XML files without the explicit dive computer information, go back to
checking the exact dive time.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Start merging dives by keeping the dive computer data from both dives

Also, note that we do *not* do the "find_sample_offset()" any more when
we merge two dives that happen at the same time - since we just keep
both sets of dive computer data around.

But we keep the function to find the best offset around, because we may
well want to use it later when *showing* the dive, and trying to match
up the different sample data from the multiple dive computers associated
with the dive.

Because of that, this causes warnings about the now unused function.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Improve on divecomputer data handling

This simplifies the vendor/product fields into just a single "model"
string for the dive computer, since we can't really validly ever use it
any other way anyway.

Also, add 'deviceid' and 'diveid' fields: they are just 32-bit hex
values that are unique for that particular dive computer model.  For
libdivecomputer, they are basically the first word of the SHA1 of the
data that libdivecomputer gives us.

(Trying to expose it in some other way is insane - different dive
computers use different models for the ID, so don't try to do some kind
of serial number or something like that)

For the Uemis Zurich, which doesn't use the libdivecomputer import, we
currently only set the model name.  The computer does have some kind of
device ID string, and we could/should just do the same "SHA1 over the
ID" to give it a unique ID, but the pseudo-xml parsing confuses me, so
I'll let Dirk fix that up.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Do not set the water salinity of a dive unless libdivecomputer supports it

It's annoying to see water salinity data in the XML that isn't relevant,
and adding the default value just because the dive got downloaded from
libdivecomputer is definitely wrong.

We should set the water salinity explicitly only if we have it
explicitly set on the dive computer.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Be much saner about merging dive computer data

Now that we have dive computer device ID fields etc, we can do a much
better job of merging the dive computer data.

The rule is

 - if we actually merge two disjoint dives (ie extended surface interval
   causing the dive computer to think the dive ended and turning two of
   those dives into one), find the *matching* dive computer from the
   other dive to combine with.

 - if we are merging dives at the same time, discard old-style data with
   no dive computer info (ie act like a re-download)

 - if we have new-style dive computers with identifiers, take them all.

which seems to work fairly well.

There's more tweaking to be done, but I think this is getting to the
point where it largely works.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Don't compile unused code to determine offset between samples

Commit bb6b6b49a6d4 "Start merging dives by keeping the dive computer data
from both dives" created a compile time warning. This simply adds an #if /

Yes, this might accelearate bit rod in the code, but I just dislike the
warning message when compiling Subsurface.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>