avoid creating a journal for a to be destroyed work package

Work packages with attachments where saved once for every
attachment upon destruction. This led to custom fields being rewritten
and a journal being created. Those created records where removed right
away, since the work package was destroyed so the problem was only
perceivable as poor performance.

On the other hand, we had reports of users not being able to destroy
work packages. While it is pure speculation that this change fixes the
problem it at least makes deadlocks less likely since journaling is
performed with a mutex and that no longer takes place now.

The `after_remove` callback is no longer necessary as journaling is
triggered in the services now.

app/models/work_package.rb

@@ -163,8 +163,7 @@ class WorkPackage < ApplicationRecord
   # test_destroying_root_projects_should_clear_data #
   # for details.                                    #
   ###################################################
-  acts_as_attachable after_remove: :attachments_changed,
-                     order: "#{Attachment.table_name}.file",
+  acts_as_attachable order: "#{Attachment.table_name}.file",
                      add_on_new_permission: :add_work_packages,
                      add_on_persisted_permission: :edit_work_packages,
                      modification_blocked: ->(*) { readonly_status? },

spec/models/work_package/work_package_acts_as_journalized_spec.rb

@@ -299,18 +299,6 @@ describe WorkPackage, type: :model do
 
         it { is_expected.to eq(@original_journal_count) }
       end
-
-      context 'attachment removed' do
-        before do
-          work_package.attachments.delete(attachment)
-        end
-
-        subject { work_package.journals.reload.last.details }
-
-        it { is_expected.to have_key attachment_id }
-
-        it { expect(subject[attachment_id]).to eq([attachment.filename, nil]) }
-      end
     end
 
     context 'custom values', with_settings: { journal_aggregation_time_minutes: 0 } do