add in limit for size of core file accepted / retraced

I don't believe we know the size of the core file when it is sent or being received, but the retracing process might be able to figure it out before it gets the core file from swift and it could just mark it as failed and delete the core file from swift then.

I don't recall exactly what prompted the reporting of this bug but I went looking for failures to retrace where the core files were large and didn't find many.

for day in $(seq -w 1 24); do for delog in $(find . -name daisy-error.log-201605$day.gz); do zgrep -E "[4-9][0-9]{8} byte core file" $delog; done; done
2016-04-30 08:29:02 [21487] [INFO] 8088a2f6-0ead-11e6-b5ae-fa163ed44aae has a 555472575 byte core file
2016-05-01 12:50:55 [7575] [INFO] 3db3e87a-0f9b-11e6-a577-fa163ef911dc has a 659132997 byte core file
2016-05-02 11:12:32 [23157] [INFO] ab97e628-1056-11e6-ba1d-fa163ed44aae has a 584719133 byte core file
2016-05-06 11:43:24 [12105] [INFO] a029cbae-137f-11e6-b4fe-fa163ebeb28a has a 451253946 byte core file
2016-05-08 05:50:24 [10666] [INFO] b5360a14-14e0-11e6-a9ae-fa163e54c21f has a 412296492 byte core file
2016-05-12 08:07:33 [6041] [INFO] 7caa2a82-1818-11e6-8039-fa163ef911dc has a 409175196 byte core file
2016-05-18 11:33:15 [27203] [INFO] 33472862-1cec-11e6-9069-fa163e171d9b has a 438441177 byte core file
2016-05-23 09:53:33 [32421] [INFO] 1ce516cc-20cc-11e6-83e5-fa163e30221b has a 410228098 byte core file

Of those crashes only ab97e628-1056-11e6-ba1d-fa163ed44aae created an issue where the retracer couldn't allocate memory, however the crash was then sent to the failed queue retracers where it succeeded. So the data doesn't indicate this is a high priority.

We could stop accepting core files for large crashes with something like this:

 $ bzr diff
=== modified file 'daisy/submit_core.py'
--- daisy/submit_core.py 2016-05-24 16:29:14 +0000
+++ daisy/submit_core.py 2016-05-24 16:44:33 +0000
@@ -117,8 +117,10 @@
             t_size = os.path.getsize(t.name)
             msg = '%s has a %i byte core file' % (oops_id, t_size)
             logger.info(msg)
- # Don't set a content_length (that we don't have) to force a chunked
- # transfer.
+ if t_size > 100000:
+ msg = 'Not writing extra large core file for %s.' % (oops_id)
+ logger.info(msg)
+ return False
             _cached_swift.put_object(bucket, oops_id, t, content_length=t_size)
     except IOError, e:
         swift_delete_ignoring_error(_cached_swift, bucket, oops_id)
@@ -233,6 +235,7 @@
     if written:
         return message
     else:
+ # don't want this to increment if it is a large core file
         metrics.meter('storage_write_error')
         return None