feat(search): Adds logic to download search results

[ERosendo]

This PR implements the backend logic for exporting search results (#599).

Key changes:

• Introduces a new rate limiter to throttle CSV export requests to 5 per day

• Adds a new setting named MAX_SEARCH_RESULTS_EXPORTED (default: 250) to control the maximum number of rows included in the generated CSV file.

• Refactors the view.py file within the search module. Helper functions related to fetching Elasticsearch results have been moved to the search_utils.py file for better organization and clarity.

• Introduces two new helper functions fetch_es_results_for_csv and get_headers_for_search_export

• Adds a new task that takes the user_id and the query string as input. It then sends an email with a CSV file containing at most MAX_SEARCH_RESULTS_EXPORTED rows.

[semgrep-app]

Semgrep found 3 avoid-pickle findings:

• cl/lib/search_utils.py
  • L342 - Triage
  • L346 - Triage
  • L430 - Triage

Avoid using pickle, which is known to lead to code execution vulnerabilities. When unpickling, the serialized data could be manipulated to run arbitrary code. Instead, consider serializing the relevant data as JSON or a similar text-based serialization format.

_{Ignore this finding from avoid-pickle}

Semgrep found 1 direct-use-of-jinja2 finding:

• cl/search/tasks.py
  • L411 - Triage

Detected direct use of jinja2. If not done properly, this may bypass HTML escaping which opens up the application to cross-site scripting (XSS) vulnerabilities. Prefer using the Flask method 'render_template()' and templates with a '.html' extension in order to prevent XSS.

_{Ignore this finding from direct-use-of-jinja2}

[mlissner]

I gave this a once-over and it feels about right. Concerns I'll highlight for you guys to consider:

1. Memory: We're putting the CSV in memory, which sure is handy. I think this is fine b/c it'll be pretty small, a couple hundred KB, right? This must be fine, but it's on my mind.

2. The fields in the result might be annoying with columns that aren't normalized to human values (like SOURCE: CR or something, and local_path: /recap/gov.xxxx.pdf instead of https://storage.courtlistener.com/recap/gov.xxx.pdf). I didn't see code to fix that, but it's probably something we should do if we can. This CSV is supposed to be for humans, in theory.

I appreciate the refactor, but I'd suggest it in a separate PR in the future, so it's not mixed in.

But this looks about right to me otherwise. :)