onlyTrashed()->forceDelete() seems to lose the SingleTableInheritance scope, deletes way more than intended about single-table-inheritance

[jwadhams]

Turned on query logging, this PHP:

\App\Models\AccountIntegrations\TP_TradeEstimate::onlyTrashed()->count();

generates this SQL:

select count(*) as aggregate from `account_integrations` where `account_integrations`.`deleted_at` is not null and `account_integrations`.`type` in (?)	["TP_TradeEstimate"]

but this php:

\App\Models\AccountIntegrations\TP_TradeEstimate::onlyTrashed()->forceDelete();

generates this SQL

delete from `account_integrations` where `account_integrations`.`deleted_at` is not null

... which suggests the problem is somehow specifically with forceDelete not a something obvious like STI scopes being cleared by the onlyTrashed scope.

[jwadhams]

OK, my current hypothesis is that this is a design error in, of all things, MassPrunable.

The implementation and unit tests of \Illuminate\Database\Eloquent\MassPrunable::pruneAll assume that you can force delete all models that meet the prunable criteria, without either prunable or pruneAll bothering to use something like withTrashed.

\Illuminate\Database\Eloquent\Builder::forceDelete, in its commentary, explicitly does NOT apply scopes, but that doesn't seem relevant to its "force" job. What it really needs to ignore is the onDelete behavior (which turns deletes into updates). If I rebuild forceDelete to basically be a clone of delete without onDelete the only tests that fail are related to pruning.

I've got an almost-ready-to-PR branch against Laravel Framework that I'll link here when I submit it. At this rate it looks like no changes to this library will be necessary, but the issue will affect any unpatched versions of Laravel.