Don't store raw source in feeds_source table

Problem/Motivation

When an import does not complete in one run and the source is fetched via HTTP, the raw source is saved in the database, in the feeds_source table. This is a problem when the raw source is very big. It can result into errors when the content is bigger than the MySQL max allowed packet. For example: if the content is 200 MB and max_allowed_packet = 128M, then it will result into a PDOException with the message "MySQL server has gone away".

Interesting to note is that content is also saved on the file system (in public://feeds) and that when an import continues, the content is taken from this file. So saving it also to the database is redundant as it is not being used!

Upon completion of the import, the content is deleted from both the feeds_source table and the file system.

How to reproduce

1. Create an importer using the HTTP fetcher and the CSV parser. Turn off "Import on submission" setting. Eventually set to import as often as possible and eventually enable "skip hash check" setting to reproduce the issue again on subsequent imports.
2. Make sure that the import cannot be completed in one run:
   
   1. Set the variable "feeds_process_limit" to a low value, for example "1". Each cycle will then import one item if the parser supports this (the CSV parser supports this setting, the Common syndication parser does not).
   2. In a custom module, alter the maximum run time of the queue "feeds_source_import". When an import is not completed in one cycle, the job will be put on a queue so multiple cycles can be ran on a single cron run. That is why setting only the variable "feeds_process_limit" is not sufficient.
      Code example:

      /**
       * Implements hook_cron_queue_alter().
       *
       * Sets runtime limit for feeds_source_import queue to 3 seconds.
       */
      function mymodule_cron_queue_info_alter(&$queues) {
        $queues['feeds_source_import']['time'] = 3;
      }
      

   3. Make sure that processing a single item takes more time to complete:
      

      /**
       * Implements hook_feeds_after_save().
       *
       * Makes that processing a single item takes at least a second to complete.
       */
      function mymodule_feeds_after_save() {
        sleep(1);
      }
      

   4. Have a CSV file with enough items. With the example values used from above, you will need at least four items.
3. Initiate the import.
4. Run cron.

Proposed resolution

When the fetcher result is saved in the feeds_source table, unset $fetcher_result->raw before serializing the object. This can be done by implementing the magic __sleep() method on it.
Possible caveat for this solution: private members on the fetcher result may not be saved? There are no private members on FeedsFetcherResult, but classes that extend it could have it, so this could potentially introduce a BC-break.

I also have plans to refactor FeedsFetcherResult a bit: the file to import will be saved at $feedsdir/in_progress; the name of the file should contain importer ID + Feed NID, the name may be hashed.

Remaining tasks

1. Write a test that ensures that the content is not saved in the feeds_source table when the import does not complete in one run. (start: #2032333-20: [Meta] Store remote files in the file system instead of in the database)
2. Write a test that ensures that the content continues were it left off (check this by altering the cache).
3. Review!

User interface changes

None.

API changes

• The class FeedsFetcherResult may get a __sleep() method, which could potentially break classes that extend FeedsFetcherResult and have private members.
• The class FeedsFetcherResult may be refactored a bit, small chance of a BC-break.

Data model changes

• The raw source is no longer saved in the feeds_source table.
• The file saved on the file system will probably be renamed to $feedsdir/in_progress/[importer_id]-[feed_nid] (file name may be hashed).