Do not cache profiles when requested via getExtendedProfileProperty

[Half-Shot]

The JS-SDK recently (#5246) introduced a cache that would locally store the state of a user's profile, which persists forever until /sync updates it with fresh information. Unfortunately, there is no upstream support for tracking federated users and so the profile ends up being incomplete.

The current behavior also stores a copy of a profile field when getExtendedProfileProperty is explicitly called, however since we can't tell if that user is "subscribed to" we don't know for sure if the cache will ever be updated.

This PR therefore removes the mechanism to cache on profile request, but keeps it for profiles we are syncing via /sync. The end result is hopefully that we always have up-to-date information for users at the cost of extra requests made to the homeserver for federated users. When the syncing mechanism matures to support federated users, this should improve still further.

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

[dbkr]

Hmm, I don't love making implementation decisions based on what hasn't yet been implemented in a particular homeserver. It will still be sort of broken because the status still won't update unless the component gets re-mounted.

The reason I added this was because otherwise the client will just keep requesting the status for users that haven't sent a status update so this will be quite a few extra requests and not just for federated users.

If the concern is that we see stale statuses from federated users, a more appropriate fix might be to have synapse just not fetch federated statuses until it also supports streaming them?