* Add progress indicators to MigrateAccountConversations

* Avoid running expensive query for explain

* Use exec_query instead of execute

* Add locality check to ActivityPub::FetchRemoteAccountService

Fix #8643

Because there are a few places where it is called, it is difficult
to confirm if they all previously checked it for locality. It's better
to make sure within the service.

* Remove faux-remote duplicates of local accounts

* Add silent column to mentions

* Save silent mentions in ActivityPub Create handler and optimize it

Move networking calls out of the database transaction

* Add "limited" visibility level masked as "private" in the API

Unlike DMs, limited statuses are pushed into home feeds. The access
control rules between direct and limited statuses is almost the same,
except for counter and conversation logic

* Ensure silent column is non-null, add spec

* Ensure filters don't check silent mentions for blocks/mutes

As those are "this person is also allowed to see" rather than "this
person is involved", therefore does not warrant filtering

* Clean up code

* Use Status#active_mentions to limit returned mentions

* Fix code style issues

* Use Status#active_mentions in Notification

And remove stream_entry eager-loading from Notification

* Add conversations API

* Add web UI for conversations

* Add test for conversations API

* Add tests for ConversationAccount

* Improve web UI

* Rename ConversationAccount to AccountConversation

* Remove conversations on block and mute

* Change last_status_id to be a denormalization of status_ids

* Add optimistic locking

Fix #8590

* Code quality pass

* Typofix

* Update applications_controller_spec.rb

* Update applications_controller_spec.rb

Fix #8327

Fix #8275

As the batch operation progresses, the statuses_stats table grows,
and the WHERE NOT IN subquery becomes more expensive

* Move status counters to separate table, count replies

* Migration to remove old counter columns from statuses table

* Fix schema file

Adopted from GitLab CE. Generate new migration with:

    rails g post_deployment_migration name_of_migration_here

By default they are run together with db:migrate. To not run them,
the env variable SKIP_POST_DEPLOYMENT_MIGRATIONS must be set

Code by Yorick Peterse <yorickpeterse@gmail.com>, see also:

https://gitlab.com/gitlab-org/gitlab-ce/commit/83c8241160ed48ab066e2c5bd58d0914a745197c

Include a dummy Account class in the migration script containing only the
attributes relevant to the migration in order to not rely as much on the
codebase being in sync with the database schema.

* Add federation relay support

* Add admin UI for managing relays

* Include actor on relay-related activities

* Fix i18n

* Add option to not consider word boundaries when filtering phrases

* Add a few tests for keyword/phrase filtering

* Add keyword filtering

    GET|POST       /api/v1/filters
    GET|PUT|DELETE /api/v1/filters/:id

- Irreversible filters can drop toots from home or notifications
- Other filters can hide toots through the client app
- Filters use a phrase valid in particular contexts, expiration

* Make sure expired filters don't get applied client-side

* Add missing API methods

* Remove "regex filter" from column settings

* Add tests

* Add test for FeedManager

* Add CustomFilter test

* Add UI for managing filters

* Add streaming API event to allow syncing filters

* Fix tests

* Switch filtered_languages to chosen_languages

* Adjust interface

* Remove unused translations

* Add autofollow option to invites

* Trigger CodeClimate rebuild

* Migration to cleanup blocked users that are still following

* use follow directly, commit schema

* Wrong exception class: ActiveRecord::RecordNotUnique, not PG::UniqueViolation

It's completely not obvious but PG::UniqueViolation is just a string inside the exception message, not the actual class of the exception

* Favourite does not have target_account_id

* Improve account index migration

- Display more progress in stdout
- Catch PG::UniqueViolation when re-attributing favourites
- Skip callbacks and validations when re-attributing other relationships

* Use in_batches to reduce table lock-up during account merge

* Use #say_with_time to benchmark each deduplication

Under rare circumstances the user record could have already been deleted before...

Fix #6937
Fix #6837
Fix #6667

Queries with the combination of account_id, id, and visibility can be
categorized in three types:
1. Querying for public and unlisted to enumerate statuses visible to
anyone.
2. Querying for public, unlisted, and private to enumerate statuses
visible to follower.
3. Querying for direct to enumerate own direct statuses.

1 and 2 is covered by the index with condition 'visibility IN (0, 1, 2)'.
It would bring better performance in case that there are many direct
statuses.

The index with condition 'visibility = 3' is just for 3. It would be much
faster to query direct statuses thanks to this query.

The total size of those two indexes are expected to be smaller than the
deleted one because they are partial and does not have to cover all the
table.