* topic/christian/analyzer-lookup-bifs:
More precise error reporting for the disable_analyzer() BiF
Add btests for the lookup_connection_analyzer_id() BiF.
Add BiF for looking up a connection's numeric protocol analyzer IDs
This replaces generic reporter->Error() calls with the builtin-specific variety,
which gives better context in the resulting error messages (such as the script
and line causing it).
Includes corresponding baseline update in one affected btest.
This adds a new lookup_connection_analyzer_id() BiF to find a given connection's
numeric identifier for a given protocol analyzer (as defined by the underlying
Analyzer::id_counter).
This enables users to call disable_analyzer(), which requires a numeric analyzer
ID, outside of analyzer_confirmation_info and analyzer_violation_info events
handlers.
* origin/topic/vern/add-del-expr:
removing now-vestigial "add" and "delete" statements
script optimization support for "add" and "delete" being expressions
"add" and "delete" are now expressions rather than statements
bug fix for dealing with illegal types of initializers
added a space when rendering some expressions so they're more readable
* origin/topic/timw/fix-coverage-part-deux:
CI: Remove --enable-werror for asan builds
CI: Run coverage builds for PRs, but only upload on master
Coverage: Ignore a few errors during generation
Coverage: don't bother ignoring non-existent bro.dir files
CI: Re-enable coverage
CI: Switch asan build back to gcc
Update cmake submodule [nomail]
CI: Avoid divide by zero error when generating coverage files
There's a bug in GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562) that
causes std::regex to emit some warnings when built with -fsanitize=address. Any
warnings that actually mean anything would be caught by the other sanitizer
builds or by the regular ubuntu24 build.
The tools used for coverage (gcov, lcov) work better with GCC. We could switch
over to similar tools for llvm, but they way they store files during coverage
builds don't work as well for us (mostly the places they store the files).
In some cases, e.g. running zeek on short pcaps as opposed to continuous packet streams, network_time() may not equal the time that was used when generating the file object.
This results in the pe.log entry having a different timestamp than its corresponding files.log entry which is strange as they refer to the exact same file.
