WIP: adapt tests to the migration from Resque to Sidekiq
Code reorganization for better readability
Added test: subscribe job, when part of an OPML import, should be able to detect if the original import job is still running.

Now that we've migrated to Sidekiq, which is multi-threaded, we should be extra careful with synchronization issues.
Minor change to detect the case in which the number of processed feeds in an OPML import is actually bigger than the total number of feeds in the OPML.

This should actually never happen, but I think this change does no harm and could save some potential trouble if there is an undetected issue in the logic that updates the number of processed feeds.
Minor change for readability.
Removed from subscribe job the logic that tried to determine if the OPML import had finished by looking at the presence of other jobs spawned during import processing.

The subscribe job is guaranteed to update the processed_feeds attribute of the import state object, even if an error is raised during subscription. So, a logic that determines if the OPML import is finished just by comparing total_feeds with processed_feeds should be enough in all cases. Simpler code, less issues.

The removed code tried to cope with catastrophic failures, like Sidekiq silently refusing to enqueue a job, or Ruby not performing the "ensure" clause of the worker's perform method. First, if we have such low confidence in our stack, it would be time to switch to another stack. Trying to fix such fundamental issues in the app only leads to madness.

Also, the removed logic had its own synchronization issues, which would be more evident in a threaded environment like Sidekiq. With Resque we could be reasonably sure that a single worker served the queue, which meant that the import job was guaranteed to finish processing before any of the spawned subscribe jobs started running. With Sidekiq hoewever there is a default of 25 threads waiting for jobs, which means that synchronization is a much bigger issue.

The old logic had a big flaw: it could decide that the import was not yet finished because the main import job was still running. This would be ok in the case in which the import job was still spawning subscribe jobs, but it could be that it has completely finished spawning subscribe jobs and is at some later point in the program, e.g. waiting to delete the .opml file from Amazon S3 (which could be a slow operation). In this last case, it could happen that the import job is never marked as successfully finished.

This situation can only happen if for some reason the ensure clause of the perform method of a subscribe job is never executed. This should not happen ever, except if ruby or sidekiq fail catastrophically and silently. I don't think it's worth it going through all the trouble of implementing more refined synchronization during opml importing, only to guard against the case of the stack just not being trustworthy. I've decided it's better to trust that the underlying framework will do its job, and implement just a simple logic of counting processed feeds from the OPML, withut querying Sidekiq for currently working or enqueued jobs.