4942 Fix document_number filtering for docket numbers with repeated values

[albertisfu]

@mlissner your observation in #4942 (comment) was correct!

The issue was indeed caused by duplicated terms in a docket number and the search analyzer used. When using the default search_analyzer, a docket number like "1:22-cr-00001" is tokenized as follows

{
    "tokens": [
        {
            "token": "1:22-cr-00001",
            "start_offset": 0,
            "end_offset": 13,
            "type": "word",
            "position": 0
        },
        {
            "token": "1",
            "start_offset": 0,
            "end_offset": 1,
            "type": "word",
            "position": 0
        },
        {
            "token": "22",
            "start_offset": 2,
            "end_offset": 4,
            "type": "word",
            "position": 1
        },
        {
            "token": "cr",
            "start_offset": 5,
            "end_offset": 7,
            "type": "word",
            "position": 2
        }
    ]
} 

This behavior is due to the remove_duplicates filter, which removes duplicate tokens. As a result, in this case, the second occurrence of "1" is removed.

Similarly, for "3:25-cv-00025", the second occurrence of "25" is removed.

This explains why a filterquery like docket_number:3:25-cv-00025 only matched up to "cv".

Solution:
The solution is to use the search_analyzer_exact for the docket_number filter. Since docket_number queries use a match_phrase query in build_term_query, they already search for exact matches. This method is also used for other filters that require exact matches, such integers as court_id and keyword fields, which are not modified at indexing time. That’s why this issue affected only docket_number, which undergoes transformation during indexing, and not other filters.

The second part of the solution is to use the docketNumber.exact field for indexing, ensuring it aligns with the search_analyzer_exact query terms.

• This was not an issue for docket number queries using the text box like q=3:25-cv-00025 because we detect the docket number in the query and convert it to a fielded docketNumber query wrapped within quotes docketNumber:"3:25-cv-00025" which looks for an exact match.
• However, I found this issue was also present in fielded queries like q=docketNumber:3:25-cv-00025 if the user didn't wrap the docket number within quotes. So I applied a fix for this case by tweaking cleanup_main_query.
• To pass a parenthetical test, it was necessary to change the docketNumber field definition in the parenthetical index because it previously didn't support an exact version of the field. However, this change won't take effect in production until we recreate the parenthetical index. Before we do that, we may want to review the entire parenthetical approach since it uses an old approach so many of its fields might require changes.

[mlissner]

Looks like we might be able to do it without re-indexing. That's nice. I don't know this code well enough, so I only gave it a glance. Onward to Eduardo for a better look.