Shim favs/subs back-compat via BBP_User_Engagements_Base

[johnjamesjacoby]

In 2.6, we changed the way that engagements are stored in the DB. There is a migration script for small bbPress installs (with less than 10k users) but there is no back-compat for larger installs that haven't upgraded yet.

We should extend BBP_User_Engagements_Base and provide back-compat for favorites & subscriptions to provide backwards compatibility to large 2.5 installations.

We'd do this by setting the "engagements strategy" in bbPress::setup_variables() based on the database version. Right now, we've hard-coded it to use the new one (BBP_User_Engagements_Meta) but we'd selectively use the back-compat one if until the database upgrade is completed.

The goal with doing so is preventing breakage for the brief period of time between bbPress files being upgraded to 2.6, and the database still being at version 2.5. For large installs, that might be days or weeks until a forum admin manually runs the upgrade routine, so it's important that we have a strategy in place for them.

Putting this in the 2.6 milestone as the final thing to do before 2.6 is released and 2.7 dev begins.

[johnjamesjacoby]

In 6842:

Engagements: move common classes out of abstraction.php.

See #3211.

[johnjamesjacoby]

In 6843:

Engagements: documentation improvements to various strategy classes.

See #3211.

[johnjamesjacoby]

In 6844:

Engagements: first pass at back-compat for pre-2.6 subscriptions and favorites

Introduces a BBP_User_Engagements_Back_Compat class with the necessary inverted methods to add/remove engagement relationships.

Needs testing, and get_query() left todo.

See #3211.

[johnjamesjacoby]

In 6876:

Engagements: next pass at back-compat for pre-2.6 user strategy.

• Renames BBP_User_Engagements_Back_Compat to BBP_User_Engagements_User so the approach is more clear.
• Fill in get_query() method, left todo from r6844.
• Move active strategy into a preloaded option, default to meta
• Set active strategy to user on failed auto-upgrade to 2.6 to maintain backwards compatibility
• Introduces sub-actions to assist with abstracting the engagement strategy setup

Fixes #3211.

[johnjamesjacoby]

In 6877:

Engagements: demystify strategy sanitization.

This change ensures that invalid/unavailable strategies are never used, and also allows for custom strategies to exist (custom table, etc...) without requiring strategy registration.

See #3211.