Allow the usage of ' ' and '/' in field names

[janheise]

Description

This PR adds support for and / in field names. This was forbidden in earlier versions due to restrictions in ES/lucene.

TODO: improve this description & changelog

Motivation and Context

The definition of Whitespace: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Character.html#isWhitespace(char)

for reference, see https://github.com/Graylog2/graylog-plugin-enterprise/issues/8169

How Has This Been Tested?

The unit tests for Messages have been modified to include whitespace & / in tests.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[kroepke]

Before merging this, we need to ensure that all places that deal with field names properly escape them, especially URL construction and notification templates.

[kroepke]

Please address the exhaustive testing before merging this.

[systemboogie]

@janheise I noticed a problem with search query auto-completion. When searching for a field name with a slash (e.g. abc/slash), auto-completion correctly suggests the field, but does not escape the slash in the suggestion...

... which then leads to an error when performing the search:

The same happens when searching for a field name that contains a space character (e.g. abc space)

[systemboogie]

@janheise Another observation related to the _exists_ operator.

Works fine for slash, e.g. _exists_:abc\/slash.

Space in a field name needs to be escaped as well (e.g. _exists_:abc\ space) and the search yields the correct results. However, the UI shows warnings.

[systemboogie]

Some more findings around auto-completion: All query input fields with auto-completion suggest a field name with slash or space correctly, but in the suggested field names, slash and space characters are un-escaped. Hopefully this is a thing that can be fixed in a central place?

• Search page > Query input field
• Search page > Search result list (message table) > Add to query
• Search page > Search filter > Query input field
• Enterprise > My search filters

---

Then I found an issue in areas where we pre-populate a query input field. Slash and space in field names are un-escaped there as well. We should escape those chars in the generated query. Some areas where I observed that until now, I guess there are more:

• Search page > Create an event definition from a value > Leads to the event definition config with query input field populated
• Alert page > Replay search

---

While testing alerts, I stumbled across an inconsistency. Consider one key-value pair abc/slash:"with slash" and another one abc/slash/2:"with slash"

• An event definition that looks for abc/slash:"with slash" does not fire an alert. Pretty expected due to the un-escaped slash
• An event definition that looks for abc\/slash:"with slash" does fire an alert. Also expected
• An event definition that looks for abc/slash/2:"with slash does fire an alert as well, despite the un-escaped slashes. And the alert correctly lists only messages with the abc/slash/2 field
• That made me check the behavior of the search page... and the displayed results are different there. A search query like abc/slash/2:"with slash" does not show a validation error (only a warning), so a user is able to submit the query. However, the search does not only show messages that contain abc/slash/2, but also unexpected ones, e.g. abc/slash and also /. Seems like the parser does not account for more than one slash in a field name or we use different search endpoints in different places or maybe even both applies

---

When replaying a search from a fired alert, the slash and space characters are un-escaped in the search query input field, but nonetheless the search results in the widgets below are correct