app: probe if any users of thread containment exist

If "thread containment" isn’t skipped the API will only return posts
whose entire ancestor chain is also visible to the current user.
For example if this contianment is active and the current user
follows A but not B and A replies to a followers-only post of B
the current user will not be able to see A’s post eventhough
per ActivityPub-semantics (an behaviour of other implementations)
the current user was addressed and has read permissions to A’s post.
(Though this semantics frequently surprise some users.)

There is a user-level option to control whether or not to perform
this kind of filtering and a server-wide config option under :instance.
If this containment is _disabled_ (i.e. skip_thread_containment: true)
server-wide, user-level options are ignored an filtering never takes
place.

This is cheked via the database function "thread_visibility" which
recursively calls itself on the ancestor of the currently inspected post
and for each post performs additional queries to check the follow
relationship between author and current user.
While this implementation introduced in
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/971
performs better than the previous elixir-side iteration due to
less elixir-database roundtrips the perf impact is still ridiculously
large and when fetching and entire conversation / context at once there
are many redundnat checks and queries.
Due to this an option to dis/enable the "containment" was added and
promptly defaulted to disabling "containment" in
593b8b1e6a six years ago.
This default remained unchanged since and the implementation wasn’t
overhauled for improved performance either. Essentially this means
the feature has already been entirely disabled oout-of-the box
without too much discoverability for the last six years. It is thus
not too unlikely that no actual users of it exist today.

The user-level setting also didn’t made its way into any known clients.
Surveying current versions of akkoma-fe, husky, pleroma-fe, pl-fe,
Mangane and just to be sure also admin-fe, fedibird-fe and masto-fe
none of them appears to expose a control for the user-level setting.
pl-fe’s pl-api acknowledges the existance of the setting in the API
definition but the parameter appears unused in any actual logic.
Similarly Mangane and pl-fe have a few matches for
"skip_thread_visibility" in test samples of user setting responses
but again no actual uses in active code.

While the idea behind the feature is sensible (though care must be taken
to not mislead users into believing _all_ software would apply the same
restrictions!), the current implementation is very much not sensible.
With the added code complexity and apparent lack of users it is unclear
whether keeping the feature around and attempting to overhaul the
implementation is even worth it.
Thus start pritning a big fat warning for any potentially existing users
prompting for feedback. If there are no responses two releases from now
on it will presumably be safe to just entirely drop it.

lib/pleroma/config/deprecation_warnings.ex

@@ -22,6 +22,27 @@ defmodule Pleroma.Config.DeprecationWarnings do
      "\n* `config :pleroma, :instance, :quarantined_instances` is now covered by `:pleroma, :mrf_simple, :reject`"}
   ]
 
+  def check_skip_thread_containment do
+    # The default in config/config.exs is "true" since 593b8b1e6a8502cca9bf5559b8bec86f172bbecb
+    # but when the default is retrieved in code the fallback is still "false"
+    uses_thread_visibility_filtering = !Config.get([:instance, :skip_thread_containment], false)
+
+    if uses_thread_visibility_filtering do
+      Logger.warning("""
+      !!!DEPRECATION WARNING!!!
+      Your config is explicitly enabling thread-based visibility containment by setting the below:
+      ```
+      config :pleroma, :instance, skip_thread_containment: false
+      ```
+
+      This feature comes with a very high performance overhead and is considered for removal.
+      If you actually need or strongly prefer keeping it, speak up NOW(!) by filing a ticket at
+         https://akkoma.dev/AkkomaGang/akkoma/issues
+      Complaints only after the removal happened are much less likely to have any effect.
+      """)
+    end
+  end
+
   def check_exiftool_filter do
     filters = Config.get([Pleroma.Upload]) |> Keyword.get(:filters, [])
 
@@ -222,7 +243,8 @@ def warn do
       check_http_adapter(),
       check_uploader_base_url_set(),
       check_uploader_base_url_is_not_base_domain(),
-      check_exiftool_filter()
+      check_exiftool_filter(),
+      check_skip_thread_containment()
     ]
     |> Enum.reduce(:ok, fn
       :ok, :ok -> :ok