Outdated merge request data can be used when getting merge requests through REST API

This potential issue popped up in MR discussion linked below: it seems we cache merge requests in REST API and the cache key is build from a few set of MR attributes/associations. But it looks like the same problem may occur whenever any other attribute/association (which is exposed through the API and is not part of the key) is changed.

The following discussion from !96860 (merged) should be addressed:

• @jprovaznik started a discussion: (+1 comment)

  If I understand it correctly, it means that this caching approach assumes that all of attributes which are exposed and can potentially change should be part of the cache key, right?

  Wouldn't we have exactly same problem when some other exposed attributes are changed? For example what happens if labels are changed? It almost looks like we would keep presenting cached/invalid list of labels because labels are not part of this key?