feat: Add Google RE2/J linear time regular expression as alternative to Java regex

[vivek807]

Fixes #19513.

Description

Add Google RE2/J linear time regular expression as alternative to Java regex

druid.regex.engine=JAVA

Supported values:

Value	Description
JAVA	Uses Java's built-in java.util.regex.Pattern engine.
RE2J	Uses Google's RE2/J regex engine with linear-time matching guarantees.

Default value:

druid.regex.engine=JAVA

RE2/J engine

Setting:

druid.regex.engine=RE2J

enables the RE2/J regex engine for ingestion task regex input formats.

RE2/J helps protect against catastrophic backtracking and Regular Expression Denial of Service (ReDoS) attacks by guaranteeing linear-time regex evaluation.

Compatibility differences

RE2/J does not support all Java regex features.

Unsupported or partially supported features include:

• backreferences
• lookbehind assertions
• some advanced backtracking behavior

Patterns using unsupported constructs will fail during regex compilation.

Example of catastrophic backtracking

The following Java regex may cause catastrophic backtracking:

^(.*a){20}$

against input such as:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX

Using RE2J avoids this issue.

Performance considerations

• JAVA may support more advanced regex syntax and behavior.
• RE2J provides safer and more predictable runtime characteristics.
• For trusted internal ingestion specs, JAVA may be preferred for compatibility.
• For externally supplied regex patterns, RE2J is recommended.

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[FrankChen021]

Severity	Findings
P0	0
P1	0
P2	1
P3	1
Total	2

Severity	Findings
P0	0
P1	0
P2	1
P3	1
Total	2

Reviewed 21 of 21 changed files.

---

This is an automated review by Codex GPT-5.5

[FrankChen021]

I reviewed the follow-up. The FlattenSpec heading has been restored, so no inline reply is needed.

Reviewed 24 of 24 changed files.

---

This is an automated review by Codex GPT-5.5

[FrankChen021]

I reviewed the follow-up. The regex engine wiring concern is handled: the module is now present in startup injection and the ingestion-facing service paths touched by the follow-up, including indexer, middle manager, overlord/sampler, peon, and coordinator standalone wiring.

Reviewed 24 of 24 changed files.

---

This is an automated review by Codex GPT-5.5

[cecemei]

I'm slightly concerned about the multiple interfaces and classes introduced in this PR, I wonder maybe we could just add RegexMatcher interface and just have two anonymous implementation from re2j and java. We could have another FunctionalInterface RegexPattern returns RegexMatcher given a string, which can be used in compiledPatternSupplier.

We could have a system wide default engine, but this could be override in RegexInputFormat.