Allow reports with long comments from remote instances, but truncate

[ThisIsMissEm]

This is an attempted fix for #24975. I didn't understand exactly the logic for the following, which is to say my confidence in this PR not having unintended side-effects is low, despite all the tests passing:

  def local?
    false # Force uri_for to use uri attribute
  end

So added explicit url_for and uri_for handling for Flag's (reports), making local? become delegated to if the account making the report is local or not.

I do note that in url_for, the line return target.url if target.respond_to?(:local?) && !target.local? may not work if the target only has a uri and not url property/method, I'm not sure if this is intentional or not?

Further, I noticed that generate_uri_for is returning not the value the code implies it may be returning, and that there was no test coverage for using ReportService to create local reports, despite this being how ReportService is used (it's used for both API reports and ActivityPub Flag's)

[ClearlyClaire]

Alternatively, you could rewrite the test as something like if: -> { account&.local? }

[ClearlyClaire]

I didn't understand exactly the logic for the following, which is to say my confidence in this PR not having unintended side-effects is low, despite all the tests passing:

  def local?
    false # Force uri_for to use uri attribute
  end

So added explicit url_for and uri_for handling for Flag's (reports), making local? become delegated to if the account making the report is local or not.

I'll double-check the possible consequences, but that sounds about right.

[ClearlyClaire]

I do note that in url_for, the line return target.url if target.respond_to?(:local?) && !target.local? may not work if the target only has a uri and not url property/method, I'm not sure if this is intentional or not?

I would say this is intentional, however, I am not actually sure all code making use of url_for expect it to be possibly nil, this might be worth double-checking.