Handle arbitrary types in bloom filter synopsis

[lava]

📔 Description

The meta index lookup would select type synopses based on the field name being looked up, without verifying that the right hand side of the query also has the corresponding type. This leads to undefined behavior for queries like s == nil or s == 123 (where s is a string field) and depending on the compiler settings also segfaults or other kinds of bad behavior.

NOTE: I'm not completely sure if the same issue exists for "normal" synopsis and we just don't notice it because the invalid call to caf::get<view<T>>() was not using complex types like std::string, or if these were typechecked somewhere else beforehand.

📝 Checklist

• All user-facing changes have changelog entries.
• The changes are reflected on docs.tenzir.com/vast, if necessary.
• The PR description contains instructions for the reviewer, if necessary.

🎯 Review Instructions

[dominiklohmann]

Generally this looks fine to me, but I would like to refrain from merging this change with such short notice before the release. This does not fix a bug that was just recently introduced, but rather a long-standing issue and we must properly evaluate whether this is the proper fix, or whether we want to look at using transparent hashing for the bloom filter.

[dominiklohmann]

Discussed with @tobim. Needs a rebase + a story for switching the result type of the lookup from optional<bool> to an enum class with three members.

[lava]

I've rebased the PR. The story (in a slightly more general form) exists as https://app.clubhouse.io/tenzir/story/19453/discussion-change-meta-index-api-to-enable-short-circuiting