Created new FeedSubscription model.

We're going to change the association between feeds and users. Instead of a simple has-and-belongs-to-many association (which implies a join table in the database to which no additional columns can be added) we will have a more complex has-many-through association. This implies creating a new FeedSubscription model, which will join users with feeds. This model is backed by a table similar to the old join table, but we can add additional columns to the table which will be available as attributes of the model.

This is necessary because we want to store, for each user-feed subscription, how many unread entries the user has in the feed. This will greatly speed up the application: instead of having to count unread entries each time the user loads the page, the current count of unread entries will be already saved in the database.

This count of unread entries will be updated in background every time an entry changes state (read/unread), instead of having to be computed every time the user loads the page.

For the moment only the FeedSubscription model, along with its unit test and database migration to create its table, have been implemented. User and Feed models have not been touched yet.

Next step will be to change the User and Feed models to redefine their association to be through the FeedSubscription model; a database migration will be implemented to remove the feeds_users table, with will be no longer necessary. This will probably mean that code like this:

    user << feed

will probably stop working, something like this will have to be done instead:

    feed_subscription = FeedSubscription.new user_id: user.id, feed_id: feed.id
    feed_subscription.save!

This means that a lot of things will be probably broken by the change and will have to be fixed. Oh, the joys of refactoring!
User model is now associated with Feed model through the FeedSubscription model. Association methods (after_add, etc) now refer to the User-FeedSubscription association, not to the User-Feed association.

This breaks many things, first of all tests! Next few commits will be devoted to fixing the app to work with the new association definition.

It is possible that the same change will have to be performed for the inverse relationship (Feed-User).
Changed the Feed-User association so that it is constructed through the FeedSubscriptions model.

Fixed the subscribing/unsubscribing code to account for the new model relationships. Lots of work to be done yet, though.
Fixed subscribing and unsubscribing from feeds so that the association methods in the User model are correctly triggered (e.g. marking all entries as unread for the user when he subscribes to a feed).

Fixed model unit tests to account for the change in associations and the new FeedSubscription model.
Fixed controller unit tests to work with the new FeedSubscription model.
Fixed background jobs and their unit tests to work with the new FeedSubscription model.
Fixed acceptance tests to work with the new FeedSubscription model.
Added method to the User model to retrieve the count of unread entries in a feed directly from the pre-calculated field in the database. Also, now when an entry changes state (read/unread) the cached unread entries count is updated accordingly.
Minor renaming of some unit tests. Added some (still pending) tests related to the cached unread entries count feature.
Divided the User model unit tests suite into several smaller files with unit tests grouped by functionality.

The User model unit tests suite was getting really huge and unmanageable. It will be easier to manage divided into smaller units.

Unit test suites related to the User model have been moved to their own folder under spec/models for better maintainability.
WIP: correctly update the cached unread entries count, every time something happens that changes the count.
WIP: proper management of the cache of the count of unread entries.

Minor renaming of some classes, methods and parameters.

Logic to add a new feed subscription to a user has been moved to the SubscriptionsManager class.

Logic to remove a subscription has been moved to the SubscriptionsManager class. FeedUnsubscriber class has been deleted because it's now redundant.

When trying to find out if an entry is unread for a user, and the user is not subscribed to its feed, an error is raised. I think it's better to raise an error in this case instead of returning a default value, which would mask a logic error.
Fixec wrong require statement (the file name has changed, but the old name was being required).
WIP: unit tests for the EntryState model, to check its lifecycle callbacks.

The idea is that most changes in the unread_entries attribute of the FeedSubscription model will be triggered by changes in EntryState model instances (creating, deleting, or changing the "read" attribute of such instances). The only exception will be the creation and deletion of the FeedSubscription database record themselves, which will be triggered by the act of a user subscribing/unsubscribing from a feed.
Many changes for the app to work with the new FeedSubscription model:

- added NotSubscribedError, which is raised when a user tries to perform an operation which requires to be subscribed, on a feed to which he's not subscribed.

- when a NotSubscribedError is bubbled to a controller, it returns a 404 HTTP response.

- SubscriptionsManager now always ensures that a user is subscribed to the feed (or not subscribed to it, in the case of the add_subscription method) before doing any operations, otherwise it raises an error.

- renaming of EntryState private methods triggered by ActiveRecord callbacks, for the sake of readability.

- added after_update callback to EntryState model. This callback decrements or increments the cached count of unread entries when a user marks an entry as read or unread, respectively.

- some User instance methods now receive full model instances (e.g. feed) instead of IDs (e.g. feed_id). This will probably be extended to all User methods in the near future.

- User callback methods delete all entry_states associated to a feed BEFORE the user is unsubscribed from the feed. Previously this was done after unsubscribingfrom the feed, but with the latest changes the app entered in a nasty callbacks loop in which it finally tried to decrement the unread entries count for a feed from which the user had already been unsubscribed. It's much more clean to delete entry_states just before unsubscribing.

- miscellaneous changes in tests to adapt to all the recent changes since introducing the FeedSubscription model.
Fixed unit tests for the EntryState model, to account for the latest changes in model callbacks.
Fixed Entry model unit tests to work with the latest changes in model callbacks.

Removed one of the Entry model unit tests. It was redundant, specifically it was testing the same behaviour as one of the EntryState unit tests.
The unread entries count besides each feed in the sidebar is obtained from the pre-calculated field in the feed_subscriptions table, instead of being calculated on each page load.

Also, a chech has been added to ensure that the user is actually subscribed to the feed before painting it in the sidebar. This is to solve a possible data inconsistency in which a user is not subscribed to a feed, but the feed is in one of his folders. This should never happen on normal use but could be caused by direct database manipulation by an admin. Of course this additional check slows down a bit loading the app, so it may be removed in the future if it seems wise to do so.