Client-side search instance, read-only against any http backend

Is your feature request related to a problem? Please describe.
To minimize server costs and maximize scalability, a public dataset site would ideally not pay for server-side search CPU at all. Imagine a public domain book library, scientific paper library, internet archive, or encyclopedia that wanted to provide full text searching while using only static or distributed HTTP-compatible storage. Serving static files through an HTTP cache can be free or very low cost as well as more immune to DoS attacks. Fundamentally there would be minimum amount of compute available and only then for updating the index, not for serving search requests.

Describe the solution you'd like
Each client would provide it's own processor power against the read-only HTTP backend storage that is made available. The clients could optionally connect (via WebSockets?) with an indexing server/cluster that has write access to the backend storage, and receive real-time updates to the index. If no real-time connection is provided, the indexers could still incrementally update the index, adding new files/splits to the backend, and then committing the changes by overwriting the hot-start file. This change would be picked up by subsequent clients or by polling from existing clients.

Most files in the storage location should be immutable by name so caching rules can be well defined. i.e. most S3 PUTs would have high max-age and immutable values set in the cache-control header. Mutable files such as the hot-start file could still have a small, configurable, cache timeout to maximize cache usage.

Describe alternatives you've considered
JavaScript based full-text search engines for static generated sites work for small amounts of content, but don't scale to gigabyte size datasets.

Additional context

• #308 could be solved in a more generic way by supporting any HTTP read-only backend
• A state-less read-only instance could run in a serverless compute (AWS Lambda) environment to minimize compute costs when queries only run occasionally. Running queries in serverless, per-request, environments could directly address the core goal of searching private datasets in a horizontally scalable way. AWS Lambda provides in-memory caching, so the state doesn't necessarily start-over every request--recently downloaded files would still be present on the next request.

No files, tests, or entry points are named; begin by reviewing the related proposal in #308 and the existing backend and indexing architecture. Done means defining a client-side, read-only search instance for immutable HTTP-backed index data, including hot-start updates and the optional live-update connection.