Add (back) rails-level JSON caching

[Gargron]

This is my idea for #11330 with prettier (and less) code, replacing render_cached_json with render_with_cache.

The :key, unless supplied explicitly, is generated from the controller name, controller action, the cache key of the object being serialized, as well as fields chosen. For example, it could look like this:

accounts/show:accounts/1:id,type,preferred_username,public_key,endpoints

When no fields are passed (such as when all fields should be rendered), it's a lot shorter:

accounts/show:accounts/1

When there's no record, the key is even simpler:

api/v1/instances/show

The method supports being passed :json a record or hash, a method name as a symbol, or a block. The latter two will only get evaluated if there is no cache. Example:

def show
  render_with_cache json: :foo
end

private

def foo
  # Heavy computing here
end

This means invocations of render_with_cache look almost identical to just using render and you don't need to think about manually specifying cache keys.

[ClearlyClaire]

The cache key being dependent on the controller's action would mean that StatusesController#show and StatusesController#activity would have different cache keys, which isn't optimal. Not sure that would really be a problem in practice, though. What is StatusesController#activity used for anyway?

[Gargron]

That would be the correct behavior because those actions return different json. Activity is used for the resolveable id of activities.

[ClearlyClaire]

Do they really return different json?
Hm, also… that's not directly related, but #activity doesn't seem to require signatures even if authorized_fetch_mode? is true

[Gargron]

The show returns a Note object, the activity returns a Create or Announce object.

[ClearlyClaire]

Oh, right! Sorry about that.

[ClearlyClaire]

I'm not super comfortable with how it moves the cache key logic in one place which tries to figure out a lot of cases by itself, but that's just my opinion. Otherwise it looks fine.