fix(parsing): Timestamp error handling in dnstap parser

[wooffie]

Summary

After my checks for illegal math I found one more testcase with panic. Now timestamp function returns Result<()> (#23048) and we can feel free to pass some errors outside.

Change Type

• Bug fix
• New feature
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

How did you test this PR?

Raw testcase:

#[test]
    fn test_raw_crash() {
        let testcase = [
            40, 226, 4, 114, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56,
            56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 77, 48, 96, 96, 96, 96,
            96, 96, 96, 96, 96, 96, 98, 96, 96, 96, 135, 96, 96, 96, 96, 96, 64, 96, 96, 96, 96,
            187, 48, 48, 48, 48, 48, 48, 48, 56, 2, 48, 0,
        ];
        let mut log_event = LogEvent::default();

        let _parse_result = DnstapParser::parse(
            &mut log_event,
            Bytes::copy_from_slice(&testcase),
            DnsParserOptions::default(),
        );


    }

Trace:

thread 'parser::tests::test_raw_crash' panicked at lib/dnstap-parser/src/parser.rs:400:18:
invalid timestamp
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/std/src/panicking.rs:692:5
   1: core::panicking::panic_fmt
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/panicking.rs:75:14
   2: core::panicking::panic_display
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/panicking.rs:261:5
   3: core::option::expect_failed
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/option.rs:2024:5
   4: core::option::Option<T>::expect
             at /home/wooffie/.rustup/toolchains/1.85-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:933:21
   5: dnstap_parser::parser::DnstapParser::parse_dnstap_message_time
             at ./src/parser.rs:397:29
   6: dnstap_parser::parser::DnstapParser::parse_dnstap_message
             at ./src/parser.rs:231:13
   7: dnstap_parser::parser::DnstapParser::parse
             at ./src/parser.rs:153:25
   8: dnstap_parser::parser::tests::test_raw_crash
             at ./src/parser.rs:1354:29
   9: dnstap_parser::parser::tests::test_raw_crash::{{closure}}
             at ./src/parser.rs:1345:24
  10: core::ops::function::FnOnce::call_once
             at /home/wooffie/.rustup/toolchains/1.85-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
  11: core::ops::function::FnOnce::call_once
             at /rustc/4eb161250e340c8f48f66e2b929ef4a5bed7c181/library/core/src/ops/function.rs:250:5
             ]

Also can check this behavior by removing changes in function but not remove new testcase.

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the "no-changelog" label to this PR.

Notes

• Please read our Vector contributor resources.
• Do not hesitate to use @vectordotdev/vector to reach out to us regarding this PR.
• The CI checks run only after we manually approve them.
  • We recommend adding a pre-push hook, please see this template.
  • Alternatively, we recommend running the following locally before pushing to the remote branch:
    • cargo fmt --all
    • cargo clippy --workspace --all-targets -- -D warnings
    • cargo nextest run --workspace (alternatively, you can run cargo test --all)
    • ./scripts/check_changelog_fragments.sh
• After a review is requested, please avoid force pushes to help us review incrementally.
  • Feel free to push as many commits as you want. They will be squashed into one before merging.
  • For example, you can run git merge origin master and git push.
• If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
  run cargo vdev build licenses to regenerate the license inventory and commit the changes (if any). More details here.

References

Additional fix to #23048

[pront]

Thanks @wooffie