Minor: change in log text.

The log line is written when a user attempts to do some operation (unsubscribe, update unread count...) on a feed to which he is not subscribed. The old log line did not accurately describe this.
Removed private method and instead perform the method operations in every place from which the method was being invoked.

It was not a good idea to extract that code to a method: it was a sanity check (validate that the user is actually subscribed to the feed on which he's trying to operate) but the desired behavior is not exactly the same everywhere (the log message if the validation fails should be different depending on where it happens in the class, to assist with debugging).
When a user queries for the unread entries count for a feed, if he's not subscribed to the feed, return zero instead of rising an error.

This should fix the following issue: when unsubscribing from a feed, the actual unsubscribing happens asynchronously in a sidekiq worker. A possible sequence of events is:

- the user requests unsubscribing from feed F. UnsubscribeUserWorker is enqueued in Sidekiq
- the browser decides to refresh feeds and unread counts by making an Ajax request (this happens every minute as long as the read view is open, and exactly when it happens is out of the user's control).
- a FeedController instance retrieves starts composing the JSON response. As the first step it retrieves from the DB all subscribed feeds; in this moment the user is still subscribed to feed F, so it is present in the set of feeds.
- the UnsubscribeUserWorker instance runs, and its perform method unsubscribes the user. Note that this is asynchronous to the FeedController instance running above.
- the FeedController instance continues running and starts iterating over the subscribed feeds (which, rememember, include feed F) to compose the JSON response. When it gets to processing feed F, the user is no longer subscribed to it.

The old behavior was to raise an error when the program reaches this point. This meant that instead of returning JSON, an HTTP error was returned, which made an error alert be displayed to the user. This was surprising for the user, to say the least.

The new behavior is to return zero. This means that no error is displayed to the user.

Currently the already unsusbcribed feed will appear in the sidebar for yet another minute, until the next automatic update. This should be fixed in the future, so that these feeds are not included in the returned JSON.

Also, the case in which the feed has not only been unsubscribed but also deleted from the database (because there were no more users subscribed) is not properly controlled. An error is likely still raised in this case; this should be fixed in the future.
Partially revert 82a00f4f6fc49078cd38dbab8a8df1118135aef1

When a user queries the unread entries count for a feed to which he's not subscribed, a NotSubscribedError is raised.
When returning to the user JSON with the subscribed feeds, if a feed becomes unsubscribed during the process (e.g. because of a sidekiq worker running asynchronously), ignore it (it won't appear in the returned JSON) and continue with the next feed, insted of completely failing the FeedsController#index action and returning an HTTP error.

This should help fix the issue described in commit 82a00f4f6fc49078cd38dbab8a8df1118135aef1: when unsubscribing from a feed, if an automated refresh of feeds in the client happens just at the same time that the UnsubscribeUserWorker instance was running, it was possible (depending on timing) that the user was shown an error alert ("error retrieving feeds information" or some such).

A desirable side effect of the changes here is that views involved in FeedsController#index and FeedsController#show no longer access the database. Any database access is performed at the controller level, and the views are kept as simple as possible; they just receive simple values and compose the JSON response with them.

Also a minor change has been made that should improve performance: when retrieving feeds in a specific folder (e.g. when the user clicks on the "all subscriptions" link under a folder), the app no longer queries the database to find out in which folder is each returned feed. In this case we already know that all feeds are in that specific folder, we can just use its ID without querying the DB or performing any other logic.
WIP: use Redis as backend for Rails cache. Added redis-rails gem in production and staging.