Skip processing stats in XML frontend

[brian-brazil]

Processing many hundreds of XML elements
that we don't need takes hundreds of milliseconds.

[frank-weinberg]

This breaks the promise that XML and JSON provide the same data set. And while none of our screens currently use those values, it can cause hard to find problems for custom screens or later additions.

At the very least guard it with a 'noStats' (or similar) flag that has to be explicitly set by a page.

[brian-brazil]

I'm hoping that we'll have no XML screens in the near-ish future (which is why I'm using this hack rather than optimising), and anyone wanting those should be pointed to the WS.

[frank-weinberg]

Given the amount of effort needed to port operator.js, I'm not so optimistic about that "near-ish".
Plus, the more I work with it the less convinced I am that the current WS interface is actually better than the XML one. (The XML interface transports the object structure a lot better than the key-value pairs used in WS. - See the problems with adding complete new objects (e.g. penalties) or updating multiple keys at once on one end and the rather involved parsing of the keys on the other end.)

[brian-brazil]

That's a matter of library support, we've not much tooling for WS yet whereas XML has all that tooling (which is what's slowing things down, as it's all enabled everywhere).

[frank-weinberg]

You may be able to hide it with library support (at the cost of computing time), but that will not change that at its heart the current JSON structure is a set of key value pairs and not a nested set of objects.

[brian-brazil]

At the data sizes we're working with, it shouldn't make the slightest difference.

[brian-brazil]

Superseded by #260