Cache some frequently used values in notifications component

[boonebgorges]

The notifications component could use a bit of minor caching. Most of the component is more or less fine without it. But there are a few queries that are called on every page, because of the toolbar and bp_options_nav. In fact, there are three DB queries on each BP pageload caused by the Notifications component, which could be consistently reduced to a single query even without persistent caching (all three ultimately result in the same DB query).

Fix incoming.

[boonebgorges]

In 7813:

Object caching for the more frequently used items in bp-notifications

Several notifications queries are made on every pageload:

• an unread count to set up navigation
• an unread count for the toolbar
• the notification items themselves for the toolbar

These three queries actually result in the identical SQL query, so we can
eliminate two of them by caching the value by the pageload. With persistent
caching, the performance benefits are obviously even greater.

The chosen technique for caching here is 'all_for_user_'. This makes
invalidation fairly straightforward, because we can simply bust the
'all_for_user_x' cache whenever a save or delete takes place on a notification
item that is related to user_x. For more complex parts of the notification
component (such as the notifications page itself), if caching is desired,
it'll probably make sense to split the query and cache individual items.

Fixes #5377

[r-a-y]

In 8176:

Notifications: Invalidate cache when a notification is updated.

Object caching was added to the notifications component in r7813.
However, the cached item was not invalidated whenever a notification
is updated (either by using one of the marked as read functions or via
using the BP_Notifications_Notification::update() method).

This commit invalidates the cache directly in the update() class
method and adds a unit test.

See #5377