Performance improvements

1) Metatiles aren't a good fit for rendering tree dots using multiple servers and workers. OTM2 serves tiles via Windshaft and mapnik. When you request a 256x256 tile, mapnik renders by default a 1024x1024 metatile, and caches the resulting 16 tiles. They're aiming at basemaps, where for example if a road segment crosses three tiles it's more efficient to render it once than three times since you'll often want all 3 tiles. That's a bad fit for OTM for two reasons. First, our tree dots are less likely to span multiple tiles. Second, since metatiles aren't shared across servers or even across workers on the same server, our AWS tiler setup (currently two tile servers with two workers each) is likely to render each metatile multiple times, making things slower rather than faster.

2) Snap-to-grid speeds up rendering but slows down database queries. A few months back I implemented an optimization where if two tree dots are in the same place we only render one of them. This did speed things up in development, but not in production. Filtering out coincident trees makes the SQL query run at least five times longer, which particularly hurts in production where we have just one SQL server and four renderers. Removing this optimization, combined with #1, should speed up rendering by as much as 75%.

3) We don't need a big buffer around tiles. When looking for objects to render on a tile, mapnik adds 64 pixels on all sides of a tile so if e.g. a label spans two tiles it will be rendered on both rather getting cut off at the boundary. Again because we're only rendering tree dots, we can reduce the buffer to 11 pixels since our biggest dot is 20 pixels. This speeds up rendering by as much as 25%

I also tried a few CartoCSS modifications, but found no useful speedups.
We may want to mention in our comment here that the buffer is dependent on the styling in https://github.com/OpenTreeMap/OTM2/blob/master/opentreemap/treemap/assets/carto/mapfeature.mms. If we decide to make bigger dots, this will have to change.

In light of that, we may want to push this magic number out to the config file, so it could be set, programmatically, by the provisioner, if we ever want/need to.