Timeline traceback collection has significant overhead

[William Grant]

python-timeline generates and stores a traceback when each timeline action (SQL, memcache, librarian, etc. requests) starts. This traceback is only used if an OOPS is created.

Profiling shows that this can be around 1.5ms per action, which is around 10% of the render time for well-optimised pages like Product:+index and Product:+sharing -- significant overhead for something that's only used when things go wrong. Most of this time goes to reading in and formatting the referenced code lines, and experimentation shows that collecting just the important bits of each frame (filename, lineno, name) and skipping the IO takes it down to around 1%. Since requests are short, it seems like we could reasonably fill in the lines and format the traceback just-in-time during OOPS serialisation, if indeed an OOPS is generated at all.

We already have our own traceback collector in lp.services.stacktrace, and it looks pretty much compatible with stdib's traceback.py. It's already split into extract/format stages, but extract still pulls in the file contents, so it would need to be split further.

[Robert Collins (lifeless)]

Please improve the oops-tools stock environment as well; nothing about
this needed improvement is LP specific