Fix mapping char_filter when mapping a hashtag

[nathanmyles]

Description

Fix the mapping char_filter to allow mapping hashtags, example:

from elasticsearch_dsl import analyzer, char_filter


STD_WITH_SPECIAL_CHARS: Final = analyzer(
    'std_with_hashtag_chars',
    type='custom',
    tokenizer='standard',
    filter=['lowercase'],
    char_filter=char_filter(
        'hashtag_char_filter',
        type='mapping',
        mappings=[
            '# => _hashsign_',
        ],
    ),
)

More details in the issue below.

Related Issues

Resolves: #7308

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/15521/
• CommitID: 01e3675
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/15522/
• CommitID: f5535d1
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/15582/
• CommitID: 022c01c
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/15583/
• CommitID: 13131f3

[codecov]

Codecov Report

Merging #7591 (1e421f9) into main (df517a6) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

❗ Current head 1e421f9 differs from pull request most recent head e83bf87. Consider uploading reports for the commit e83bf87 to get more accurate results

@@             Coverage Diff              @@
##               main    #7591      +/-   ##
============================================
- Coverage     70.84%   70.75%   -0.10%     
+ Complexity    56508    56114     -394     
============================================
  Files          4721     4680      -41     
  Lines        267470   266072    -1398     
  Branches      39211    39069     -142     
============================================
- Hits         189477   188247    -1230     
+ Misses        61970    61844     -126     
+ Partials      16023    15981      -42     

Impacted Files	Coverage Δ
...n/java/org/opensearch/index/analysis/Analysis.java	83.96% <100.00%> (-0.13%)	⬇️

... and 639 files with indirect coverage changes

[dblock]

With this change we have two code paths, one that removes comments and another that doesn't. Why? In what cases would one want both behaviors? What tests break if you get rid of supporting comments altogether?

Assuming the answer is "we don't need comments", for 3.0 we could just do it. Then we can discuss options for backporting this into 2.x, for example we could tream # => as something special.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      1 org.opensearch.remotestore.SegmentReplicationUsingRemoteStoreIT.testReplicaHasDiffFilesThanPrimary
      1 org.opensearch.remotestore.SegmentReplicationUsingRemoteStoreIT.testPitCreatedOnReplica
      1 org.opensearch.indices.replication.SegmentReplicationAllocationIT.testSingleIndexShardAllocation

• URL: https://build.ci.opensearch.org/job/gradle-check/17478/
• CommitID: e83bf87
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[nathanmyles]

@dblock I think this PR is pretty much good to go, just hitting some pipeline instability. I've been rebasing when I can, hopefully it'll be resolved soon.

[nathanmyles]

@dblock Looks like the checks are all green now, though I haven't rebased this today. Is this good to go now? Or should I rebase this again today?

[dblock]

Merged, thank you. Watch the backports for failures, might need manual ones.

[opensearch-trigger-bot]

The backport to 1.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-1.x 1.x
# Navigate to the new working tree
pushd ../.worktrees/backport-1.x
# Create a new branch
git switch --create backport/backport-7591-to-1.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e049338c714db77517c5e8bb94b6b24a7b0a3281
# Push it to GitHub
git push --set-upstream origin backport/backport-7591-to-1.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-1.x

Then, create a pull request where the base branch is 1.x and the compare/head branch is backport/backport-7591-to-1.x.

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-7591-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e049338c714db77517c5e8bb94b6b24a7b0a3281
# Push it to GitHub
git push --set-upstream origin backport/backport-7591-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-7591-to-2.x.

[opensearch-trigger-bot]

The backport to 1.3 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-1.3 1.3
# Navigate to the new working tree
pushd ../.worktrees/backport-1.3
# Create a new branch
git switch --create backport/backport-7591-to-1.3
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 e049338c714db77517c5e8bb94b6b24a7b0a3281
# Push it to GitHub
git push --set-upstream origin backport/backport-7591-to-1.3
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-1.3

Then, create a pull request where the base branch is 1.3 and the compare/head branch is backport/backport-7591-to-1.3.

[dblock]

Backports will need to be manual :( will you do them please @nathanmyles ?

[nathanmyles]

Backports will need to be manual :( will you do them please @nathanmyles ?

Yep, I'll look at these. I'll link the PRs to this one. Let me know if there's anything special I should do.

[nathanmyles]

@dblock Created the backport for 1.3: #8121

Let me know if this looks correct and I'll do the rest.

[kartg]

@nathanmyles #8121 has been merged. Please create similar backport PRs for t 1.x and 2.x branches. Thank you!

[nathanmyles]

@kartg Created the other backport PRs, let me know if there's anything else I need to do.

Also, would you know when this change would make it into the AWS opensearch versions?

[dblock]

@nathanmyles Can't confirm or deny which versions of AWS OpenSearch it will go into and when, but if you do open a customer support ticket they can certainly find out and track it for you.