Switch internals to use Lambda proxy integration

[jamesls]

This change replaces the VTL related configuration with AWS
Lambda proxy integration.

See: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html

For the most part this is a transparent change to the user, but with a
couple of additional benefits:

• Users can return customer response bodies, headers, and status codes
• Slightly faster deployments because we no longer have to configure
  error regex's for each of the built-in-regex types.

Internally, this simplifies things. We don't have to manage VTL for
doing the full passthrough. This approach was taken only because Lambda
proxy integration didn't exist yet. Now that it does, switching over
makes sense.

In terms of implementation, the only notable thing was that I had to
move some of the processing into the chalice handler that was previously
handled by API gateway. This includes:

• JSON serialization. The response body we need to return from the
  lambda function must now be a string. Previously we were returning
  any python type and relying on lambda to serialize the python data
  structure for now. Now this happens in the chalice handler. This
  also means we can expand our serialization support for JSON that was
  difficult to do previously (for example automatically serializing
  datetime objects).
• CORS support for any view function written in python. We could
  leverage the integration response to inject the CORS headers needed.
  This now happens in the chalice handler. The OPTIONS request is
  still driven entirely by API gateway so we're still able to bypass
  Lambda for OPTIONS.

And finally, there are a couple of user facing changes (I'll add these
to the documentation/ugprade notes):

• Uncaught exceptions are now InternalServerError instead of
  ChaliceViewError when not running debug mode.
• In debug mode, the original traceback (as a string) is sent as
  the entire request body. Previously, we were relying on Lambda
  to serialize the stack trace into a JSON object, where the traceback
  was a list of lines. I think this results in an easier to debug
  stacktrace.

Wanted to get this out for any early feedback, but there's a couple of pending things pending I need to do:

• Documentation
• Need to figure out claims key. This was originally a top level key,
  and I believe this is now moved into the request context. Need to double check.
• Another pass of removing dead code

[codecov-io]

Codecov Report

Merging #240 into master will decrease coverage by -0.03%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master     #240      +/-   ##
==========================================
- Coverage    79.2%   79.17%   -0.03%     
==========================================
  Files          13       13              
  Lines        1510     1508       -2     
  Branches      198      197       -1     
==========================================
- Hits         1196     1194       -2     
+ Misses        259      257       -2     
- Partials       55       57       +2

Impacted Files	Coverage Δ
chalice/init.py	100% <ø> (ø)	✅
chalice/deployer.py	71.62% <100%> (-0.87%)	❌
chalice/local.py	94.23% <91.66%> (+0.73%)	✅
chalice/app.py	94.81% <93.33%> (-1.32%)	❌

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f1045ba...fdc4e61. Read the comment docs.

[jamesls]

One small change I'm going to make. With the proxy integration we don't provide the requestTemplates for content-types which means that you don't get the 415 response for undeclared content-types.

To support this I'll need to add this behavior into the chalice lambda handler. Might be worth dropping support for this in a future release but for now I'll keep those compatible.

[kyleknap]

🚢 The added functionality seems really useful.