[r=gz,allenap][bug=][author=jameinel] Change nodegroups/UUID/?op=node_hardware_details=XXX to directly serialize the response, rather than having Piston do it.

It turns out that Piston's default stream is using encode_ascii=False, which has a 10x performance overhead. Presumably it is because it is passing bad regex's over the data to check for characters it doesn't like. This one change essentially halves the time to rebuild a tag (from ~27s for 10,000 nodes down to 14s).
This now properly swings the balance so that the MAAS appserver consumes less CPU in a given request than the celeryd workers processing the content. (With 2 tags being updated concurrently, I get 2 celeryd at 60% cpu, and one maas at 32%cpu).

The other tweak is to change the number of hardware details we request in one batch. We can return 100 nodes in < 100ms. That means that the connection and request overheads start to be a large portion of the conversation. At a batch size of 1000, the celeryd workers go up to 70-80% and the maas server drops to 15-30%. Rebuilding a single tag is down to 12s. Going up to a batch of 5000 still takes 12s to build a tag, though the CPU consumption does hit 100% for the celery worker. However, the extra memory consumed in the content starts showing up (24MB at 1k nodes, 120MB at 5k nodes). 1k nodes seems to be the sweet spot.