fix(search): match names, tags and paths as indexed [opensearch]

[fschade]

Description

Name, title and tags mappings were created implicitly by openSearch without any direct mapping.
A name or a tag now matches as a whole and is not cut off after 256 characters anymore.

A path is indexed with its case, so searching inside /Documents or /documents finds the files in it, folder deletion now cleans up the index correctly too.

Bleve boolean queries like hidden:true was compiled as a string which failed to resolve.

Please read services/search/MIGRATION.md, the update involves some manual steps!

Motivation and Context

Searching for a name, a tag or inside a folder returned wrong or no results.

How Has This Been Tested?

• unit & acceptance tests
• lab installation

Types of changes

• Bug fix
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation added

[codacy-production]

Not up to standards ⛔

🔴 Issues 2 minor

Alerts:
⚠ 2 issues (≤ 0 issues of at least minor severity)

Results:
2 new issues

Category	Results
CodeStyle	2 minor

View in Codacy

🟢 Metrics 17 complexity · 9 duplication

Metric	Results
Complexity	17
Duplication	9

View in Codacy

🟢 Coverage 73.53% diff coverage · 0.00% coverage variation

Metric	Results
Coverage variation	✅ 0.00% coverage variation (-1.00%)
Diff coverage	✅ 73.53% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (0c601bb)	84494	19647	23.25%
Head commit (a4730b2)	84510 (+16)	19648 (+1)	23.25% (0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3408)	34	25	73.53%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[butonic]

I cannot parse this line ... can you make it more explicit? what does $OS have to do with this?!?

[butonic]

Ah ... {$OS} as in {{host}}.

[dschmidt]

LGTM

[butonic]

do I get that right: if between these two lines a new file is added in the web ui ... It will create an index

without our analyzer and mappings, ...

and the index needs to be deleted again? How does this relate to line 17-18?

[butonic]

[...] Search keeps working while it runs,
documents get correct one by one, and the run can be repeated at any time.

So I can implement a migration for kubernetes that runs while opencloud is running? It just can't index new documents while the opencloud-resource index is closed? That contradicts line 32:

# stop opencloud

why?

[butonic]

This really is what bothers me. It prevents pods from starting up. So I cannot upgrade the image first and then do a migration of the index in the background. Why not? Why do we prevent that? Why does the search process have to DIE and kill the whole process, just because the index is not correct. We should degrade gracefully and queue the search events .... which we do, because we have nats. we could just tune the search queue to keep more than 1000 events. That would allow locking the index and running the service in a degraded state ...

Good questions raised by @butonic, wouldn't approve merging it currently