Format frame locals when captured

[living180]

Before this commit, if ENABLE_STACKTRACES_LOCALS was True, each stack frame's locals dict would be stored directly in the captured stack trace, and only converted to a string once the stack trace was rendered. This means that for panels, such as the SQL Panel, which do not render the stack traces until later after they have all been captured, it is quite possible that the values in the locals dicts at the point when the stack trace was rendered would no longer be the same as they were at the time when the stack trace was captured, resulting in incorrect values being displayed to the user.

Fix by converting the locals dict to a string immediately when it is captured (in the get_stack_trace() function as well as in the deprecated tidy_stacktrace() function) instead of in the render_stacktrace() function.

I realize that this represents an internal API change, as now the last item of the tuples returned by get_stack_trace() will now be a string rather than a dict. However, this is not actually a documented public API and I do not expect any third-party panels to be trying to inspect or use the locals dicts from the stack traces directly, even if they are using get_stack_trace() (or more likely, get_stack() and tidy_stacktrace()). But if there are concerns about this, I have some thoughts about possible ways to address it.

[tim-schilling]

The concern here is would this recording evaluate anything in the stack, such as a generator or callable that would then prevent the application (not the toolbar) from operating as expected?

[living180]

I don't expect so. The new code is using the exact same mechanism to convert to a string (pprint.pformat()) as the old code, it just shifts when it runs. And .pformat() uses repr() internally, so I don't think it should cause any problems with generators or callables. Of course, with Python's full dynamism, it is certainly possible to create a local variable that does Bad Things™ when its repr is generated, but I think that would have to be deliberate and not something that would come up with normal code.

[living180]

Also, the Cache panel actually does exactly this right now, because it calls render_stacktrace() which internally calls pprint.pformat() when recording each call. So if there were any problems with this, they would have already been hit in the Cache panel.

[matthiask]

Makes sense.

[tim-schilling]

Thank you for the well written changelog @living180!