Disable server-side search on ReadTheDocs

Value 0 currently provides highest "score boost" and makes statement
definitions appear on top of seach results, which seems sensible to me.
With this change search for "max-cache-size" now returns its definition
at the very top.

This change is very obscure because "priority" field in Sphinx API is passed
through several layers down to client-side JavaScript.
In the end the "priority" value stored in search index is used by
performObjectSearch() function in JavaScript, which then **uses the
priority value as an index into Scorer.objPrio array** and adds value
from this array to the current "score". Priority 0 - thus index 0 - has
a code comment "used to be importantResults" and indeed has highest
score out of available values.

Beware: ReadTheDocs uses server-side search and might or might not be
affected by this change.

.readthedocs.yaml

@@ -0,0 +1,25 @@
+# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
+
+version: 2
+
+# Set the version of Python and other tools you might need
+build:
+  os: ubuntu-22.04
+  tools:
+    python: "3"  # last stable CPython version
+
+# Build documentation in the doc/arm/ directory with Sphinx
+sphinx:
+   configuration: doc/arm/conf.py
+
+# If using Sphinx, optionally build your docs in additional formats such as PDF
+formats: all
+
+python:
+   install:
+     - requirements: doc/arm/requirements.txt
+
+# disable server-side search as it gives worse results than Sphinx built-in
+search:
+  ignore:
+    - "*"

doc/arm/_ext/iscconf.py

@@ -380,7 +380,8 @@ def domain_factory(domainname, domainlabel, todolist, grammar):
                 "label": domainlabel + " statement",  # description for index
                 "docname": self.env.docname,
                 "anchor": anchor,
-                "priority": 1,  # search priority
+                "priority": 0,  # highest search priority
+                                # (maps to index in JavaScript Scorer.objPrio)
             }
 
             if name in self.data["statements"]:

doc/arm/troubleshooting.inc.rst

@@ -80,8 +80,12 @@ Inspecting Encrypted DNS Traffic
 By definition, TLS-encrypted traffic (e.g. DNS over TLS, DNS over HTTPS)
 is opaque to packet sniffers, which makes debugging problems with
 encrypted DNS close to impossible. However, Wireshark_ offers a
-solution_ to this problem by being able to read key log files. In order
-to make :iscman:`named` prepare such a file, set the ``SSLKEYLOGFILE``
+solution_ to this problem by being able to read key log files.
+
+.. envvar:: SSLKEYLOGFILE
+
+In order
+to make :iscman:`named` prepare such a file, set the :envvar:`SSLKEYLOGFILE`
 environment variable to either:
 
 - the string ``config`` (``SSLKEYLOGFILE=config``); this requires
@@ -108,7 +112,7 @@ environment variable to either:
    strongly discouraged as it will likely make the key log file
    unusable.
 
-When the ``SSLKEYLOGFILE`` environment variable is set, each TLS
+When the :envvar:`SSLKEYLOGFILE` environment variable is set, each TLS
 connection established by :iscman:`named` (both incoming and outgoing) causes
 about 1 kilobyte of data to be written to the key log file.