This largely copies over Spicy's `.clang-format` configuration file. The
one place where we deviate is header include order since Zeek depends on
headers being included in a certain order.
* origin/topic/neverlord/version-header:
testing/zeek-version-link: Assume nm is there
Drop dependency for zeek_dynamic_plugin_base
Fixup ifdef check in Plugin.h
Update cmake_minimum_required() in test plugins
testing: Add zeek-version-link tests
Clean up ZEEK_CONFIG_SKIP_VERSION_H issues
cmake-format during merge
Conceptually, a TCP-based application analyzer should not need any
knowledge about the underlying TCP analysis; it's supposed to just
process its reassembled input stream as it's handed over. But our
analyzers break that assumption at a few places because sometimes
knowledge about the TCP state of the connection can be helpful for
heuristics. This is fine as long as there actually *is* a TCP parent
analyzer available. Sometimes, however, there isn't: if the payload
stream is encapsulated inside another application-layer protocol, the
semantic link to TCP is broken. And if the outer connection is even
UDP, then we don't have a TCP analyzer at all.
We didn't handle this situation well so far. Most analyzers needing
TCP state would just crash if there's no TCP analyzer (in debug mode
with an `assert`, in release mode with a null pointer deref ...). Only
HTTP did the right thing already: check if TCP is available and adapt
accordingly.
We know extend that check to all other analyzers as well: all accesses
to `TCP()` are guarded, with reasonable defaults if not available.
It's actually a pretty small change overall, which is evidence for how
little this layering violation actually matters.
The existing behavior is what's causing
https://github.com/corelight/zeek-spicy-openvpn/issues/3.
This enables locating the headers within the install-tree using the
dirs provided by `zeek-config --include_dir`.
To enable locating these headers within the build-tree, this change also
creates a 'build/src/include/zeek -> ..' symlink.
Also now uses CMake's ENABLE_EXPORTS target property for the zeek
executable to ensure symbols are visible to plugins. Prior to CMake
3.4, the policy was to export symbols by default for certain platforms,
but later versions need either the explicit target property or policy.
