Co-authored-by: Jean Boussier <jean.boussier@gmail.com>

Co-authored-by: Matthew Ford <matt@bitzesty.com>

Fixes #23472

* Apply Rubocop Rails/WhereNot

* Update spec for where.not

* Apply Rubocop Performance/BlockGivenWithExplicitBlock

* Unprefix used block parameter

* Autofix Rails/EagerEvaluationLogMessage

* Update spec for debug block syntax

* Add tests

* Fix account activation being triggered before email confirmation

Fixes #23098

* Add option to make the landing page be /about even when trends are enabled

* Restablish /explore as landing page by default

* Add confirmation screen on moderation actions

* Add flash notice when a report has been processed

* Refactor tests

* Add tests

* Validate internal actor

* Use “internal.actor” by default for the server actor username

* Fix instance actor username on the fly if it includes ':'

* Change actor name from internal.actor to mastodon.internal

* Change domain block CSV parsing to be more robust and handle more lists

* Add some tests

* Improve domain block import validation and reporting

* Do not offer to mark statuses as sensitive if there is no undeleted status with media attachments

* Fix crash when marking statuses as sensitive while some statuses are deleted

Fixes #21910

* Fix multiple strikes being created for a single report when selecting “Mark as sensitive”

* Add tests

* fix(status): remove send usage for private unlink_from_conversations

- make unlink_from_conversations public method
- rename unlink_from_conversations to unlink_from_conversations!
- fix send call on private method in statuses_vacuum and batched_remove_status_service

* fix(feeds_vacuum): replace find_in_batches with in_batches

because active record query results should be a little more efficient than
itterating with map and each. Postgres can grasp such lists of ids much quicker
than ruby can.
Will probably make allmost no difference, but cannot hurt either.

* Make autosuggest for mentions return followed accounts first

This makes it so that (when elasticsearch is disabled) when a user types '@foo' in the compose box, they are first going to get accounts they follow ordered by the ranking algorithm, and then second they will get accounts they do not follow, also ordered by the ranking algorithm.

This makes behavior more consistent with user expectation and also with results when elasticsearch is enabled.

* Fix ranking order to correct direction

* One more fixup per @gargron suggestion

* Tweak to ranking to no longer include following modifier