Skip database_metadata cleanly and report the schema version it carries

[dchaudhari7177]

Closes #332.

What was actually wrong

The database_metadata skip the issue asks for is already there — but it is unreachable on exactly the profiles that hit this, because the version check guarding it raises first:

if item['key'] == b'database_metadata':
    if item['value'] != b'1':
        log.warning(f' - Expected type 1; got type {item["value"].encode()}. ...')
    continue

item['value'] is bytes. bytes has no .encode(). So on any store whose version is not b'1' — b'2' is what the corpus carries — that line raises AttributeError before reaching the continue, and the record falls through to the outer handler as Exception parsing SiteDataProto. That is the traceback in the issue, and it is why it looks like the record is being parsed as a proto when the code plainly says to skip it.

So this is the str/bytes mix-up the issue's closing note asks for a glance at. It is not near the problem; it is the problem.

Nothing was ever lost — the record was skipped either way, just through the exception handler instead of the branch written for it.

The fix

• Decode rather than encode, so the branch reaches its continue.
• Surface the schema version as parser context rather than discarding it, as the issue suggests: info at the expected version, a warning otherwise. A schema change is exactly what would make this parser's output quietly wrong, so it is worth saying out loud.
• The expected version becomes a module-level constant next to SECONDARY_CACHE_DIRS.
• Reword the message. The old text read Trying to parse anyway. immediately before a continue, which reads as a contradiction — it meant the rest of the store, not this record.

Verification

Three tests driving get_site_characteristics with a stubbed get_ldb_records, covering b'1', b'2' and an undecodable value. All three fail on main:

FAILED test_the_expected_version_is_skipped_and_reported
FAILED test_an_unexpected_version_warns_without_raising
FAILED test_an_undecodable_version_still_does_not_raise

Full suite on this branch: 242 passed, 2 skipped, 80 subtests passed.

I did not have the magnet.ctf_2020 corpus dataset to hand, so the reproduction here is the synthetic record from the issue's own log line rather than a corpus run — the record shape is copied verbatim from it.

[RyanDFIR]

Thanks! Code looks good. However,

b'2' is what the corpus carries

Is this true? I have not seen a 2 in the wild. The code works regardless though.