Template rendering should be async

[mkantor]

Right now handlebars templates are rendered on the thread that's handling the request. I think this could result in denial-of-service if all threads in the actix worker pool are busy rendering templates when a new request comes in. I haven't personally observed this, but it can be confirmed with some load testing (maybe using templates that get content from a slow executable or large static file).

The handlebars library is inherently blocking, but Operator's availability could still be improved by moving rendering to another thread (and preferably deferring it until the Stream is polled).

Unfortunately there are tradeoffs regarding how render errors are surfaced. Currently clients get a nice HTTP 500 if a template explodes, but with this change they'd become stream errors (which are not as obvious in browsers). Executables already work like that (an executable which exits with failure is still 200 OK), so maybe that's okay.

[mkantor]

I did some exploration on this a while ago, but decided to wait until actix-web v4 and handlebars v4 are out of beta to really dig in. I've forgotten the details by now, but there are some API changes in handlebars especially that should make this easier to implement (I think they were related to sunng87/handlebars-rust#395 and sunng87/handlebars-rust#390).

[mkantor]

Should keep an eye on sunng87/handlebars-rust#436, and consider looking into that myself if it's been abandoned. It would be awesome if handlebars-rust had async render APIs, and even better if it supported async helpers too.

[mkantor]

spawn_blocking or something like it may be the way to go here.

In any case, now that actix-web v4 has been released the first step should be migrating to that (which will also bring in a modern version of Tokio).