Add optional OAuth application to reports

[ThisIsMissEm]

This allows moderators to see the OAuth Application name that was used to create the report, helping to identify applications that are not implementing the reports API fully, causing low-quality reports. For now, we can only display the name as we do not have any way for moderators or administrators to interact with OAuth Applications

Note: Reports created from the Mastodon Web UI will only have an application associated if there is a superapp Doorkeeper::Application in existence. In my testing environment, I'd deleted that oauth_application, and consequently was seeing no application for the web UI.

UI in the Admin Reports interface looks like the following, if an Application is set:

Fixes #30510

[ThisIsMissEm]

So on reports from the Web UI not being created with an Application, it looks like the Web UI doesn't always get the application because of this line:

https://github.com/mastodon/mastodon/blob/main/app/models/session_activation.rb#L65

Which basically means if the database doesn't have a superapp (which seems to be created via db:seed)

Doorkeeper::Application.create_with(name: 'Web', redirect_uri: Doorkeeper.configuration.native_redirect_uri, scopes: 'read write follow push').find_or_create_by(superapp: true)

Then no Doorkeeper::Application will exist for the Web UI — We may also want to change the default application name to Mastodon Web instead of just Web.

In other places we do this with something that automatically creates the expected recorded if it does not exist, e.g., in Account::FinderConcern, we do:

    def representative
      actor = Account.find(Account::INSTANCE_ACTOR_ID).tap(&:ensure_keys!)
      actor.update!(username: 'mastodon.internal') if actor.username.include?(':')
      actor
    rescue ActiveRecord::RecordNotFound
      Account.create!(id: Account::INSTANCE_ACTOR_ID, actor_type: 'Application', locked: true, username: 'mastodon.internal')
    end

We may want something similar for the OAuth Applications where we have a Doorkeeper::Application.webapp that does similar logic to ensure the record always exists for the Web UI OAuth Application.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.

[github-actions]

This pull request has resolved merge conflicts and is ready for review.

[oneiros]

We may want something similar for the OAuth Applications where we have a Doorkeeper::Application.webapp that does similar logic to ensure the record always exists for the Web UI OAuth Application.

I like that idea! And maybe the seed file just calls this method to ensure the webapp oauth application is always consistent.

I think overall this PR is already quite complete and could be merged. Would you still like to add this as part of this PR or in a new, later one?

[ThisIsMissEm]

@oneiros I think I'd rather do the Doorkeeper::Application.webapp in a separate PR.