[regression] COUNT aggregation no longer outputs count value for some fields

It seems like string based fields work fine (tested the output of COUNT on the name and that works without the fixed) so perhaps it's a numeric field issue?

That breaks testFieldAggregationSettings again, gonna have to dig further into this

Test is correctly failing now:

       ├ Failed asserting that two strings are equal.
       ┊ ---·Expected
       ┊ +++·Actual
       ┊ @@ @@
       ┊ -'4'
       ┊ +'Thu,·1·Jan·1970·-·10:00\n

I'm debugging how views renders this stuff 🤯

When we get to StylePluginBase::elementPreRenderRow we have the correct count value in $data['#row']. What's happening is that value of 4 is being passed to the timestamp formatter which results in the Jan 1 1970 date (unix epoch)

Before 🐛 Decimal separator and decimals settings ignored when aggregating decimal fields Needs work , the field handler was being overridden to numeric, therefore $field in that preRender was the NumericField plugin, not EntityField.

Confirmed this isn't just an issue with COUNT either, SUM etc have the same behaviour. I'm starting to think we do need to revert here and come up with a proper fix. The field handlers should be overridden because we don't want to go through the EntityField plugin when outputting aggregation data.

I also confirmed this issue with other field types such as Link

The contrib module Fraction is also affected by this, with aggregation values disappearing.

In Core 10.4.5 the SUM output used Drupal\views\Plugin\views\field\NumericField, but in 10.4.6 it turned up in a Drupal\fraction\Plugin\views\field\FractionField using Drupal\fraction\Fraction\FractionItem::setValue(['numerator' => NN.NN]). setValue wasn't expecting such a value (normally it would be presented with FractionItem::setValue(['decimal' => NN.NN]) or ['numerator' => X, 'denominator' => Y]) resulting in the value always being empty as per the FractionItem::isEmpty().

Using both AUM & AVG in the same view ends up with one affecting the other, where in 10.4.5 that did not happen. I haven't figured out where that is happening.

I can also confirm this issue using commerce_reports. This is a major problem as these reports are essential for the stores.

Since @catch reverted the other issue, I caught up the branch to see if it now passes as I assume is expected now.

Rescoping this issue for improved test coverage now that the regression was reverted.