Change caching strategy for shared groups

Many users are complaining that changes to LDAP groups are not being reflected in rosters quickly enough. There are two layers to this:

The roster code retrieves group information by calling GroupManagergetGroups(User). At the moment, there is no caching in this method although it should be added. The entire roster is then cached, included shared group information.

Because of the roster caching logic in place, it makes it very frustrating for people to see group changes take effect. First, because they'll only see changes when logging out and then back in. Second, because the roster is cached, it can take 6 hours to see changes. People generally resort to just shutting down the server.

The first step could be to change how roster caching works. I'd like to see if we could cache the db roster data but then dynamically build out the shared roster information. I'm not sure how expensive the shared roster group calculations are, which would dictate the feasability of this. Assuming it's not too expensive, if the shared group data was dynamic, then it would be GroupManager.getGroups(User) caching that would dictate how quickly changes in the back-end groups were reflected in rosters.

Second, we should try to figure out if it's possible to push roster changes to a user. An idea: have a flag in the roster code that says whether to check for roster changes on a periodic basis. Any time an external group system is used, the flag would get set by that provider. So, every X hours that a user is logged in, recalculate the shared group portion of their roster. If it's changed, send those changes to them dynamically. This would mean that if someone changes a group in LDAP, after X hours everyone from that group that continues to be logged in will see that change.