Remove DrushBatchContext magic wrapper for batch .

[halisonfernandes]

It should fix this issue #5009

Tests are passing.

Summary:
The DrushBatchContext wrapper is causing issues to keep the batch $context values. It's mainly used for logging, but it can be done in the operations level instead of overriding the $context type.
The variable $context['error_message'] is only being used by the drush batch processes and we can use Drush::logger()->error(); as a replacement.
After this change, we can use the $task_message variable to retrieve the $context['message'] value and log it to the user.

I tested the updb in one of my sites and this is the output:

 ----------------------- ------------------------------- --------------- ------------------------------------------------------------------------------ 
  Module                  Update ID                       Type            Description                                                                   
 ----------------------- ------------------------------- --------------- ------------------------------------------------------------------------------ 
  lightning_media_image   9001                            hook_update_n   9001 - Downloads the Cropper JavaScript library if needed.                    
  block_content           entity_changed_constraint       post-update     Clear the entity type cache.                                                  
  ctools                  remove_entitybundleconstraint   post-update     Invalidate the service container to force EntityBundleConstriant is Removed.  
  webform                 ckeditor                        post-update     Move from custom CKEditor to hidden 'webform_default' text format.            
 ----------------------- ------------------------------- --------------- ------------------------------------------------------------------------------ 


 Do you wish to run the specified pending updates? (yes/no) [yes]:
 > 

>  [notice] Update started: lightning_media_image_update_9001
>  [notice] Update completed: lightning_media_image_update_9001
>  [notice] Update started: block_content_post_update_entity_changed_constraint
>  [notice] Update completed: block_content_post_update_entity_changed_constraint
>  [notice] Update started: ctools_post_update_remove_entitybundleconstraint
>  [notice] Update completed: ctools_post_update_remove_entitybundleconstraint
>  [notice] Update started: webform_post_update_ckeditor
>  [notice] Update completed: webform_post_update_ckeditor
 [success] Finished performing updates.

[weitzman]

This is ancient code and I'm a bit hesitant to remove it as I dont grok it well. It went in 13 years ago at https://www.drupal.org/node/1186480. Alas @jonhattan hasn't been active here for years.

Thanks for the deep dive. I've merged this into 12.x, since the tests suggest its safe. I'm inclined to leave 11.x alone.

[jonhattan]

That code was an improvement introduced in the Drupal 6/7 + PHP 5.x epoch. A lot has changed since, and the regression may by anywhere, or perhaps the code had a bug that didn't manifest until recent.

FWIW The goal was to log messages generated within the operations (ie. Indexing item i of n) rather than between operations. I guess this is now lost - not the worst thing.

[halisonfernandes]

Thanks for merging.

@jonhattan the main difference is that now it's not possible to log messages in the middle of the operation using the $context['message'] object, but the message will still be logged at the end of it. The recommendation would be to use the logger object or simply change the text to be Indexed i item of n instead of Indexing item i of n as it will be logged at the end of the operation only.

Having a quick look at the search_api module, it's doing it already:

      // Display progress message.
      if ($indexed > 0) {
        $context['message'] = static::formatPlural($context['results']['indexed'], 'Successfully indexed 1 item on @index.', 'Successfully indexed @count items on @index.', ['@index' => $index->label()]);
      }