Revisit and clean up Sentry integration

[Mr0grog]

In #213, I am upgrading Sentry to v2. We have a few hacks around it in the diff server that I don’t think are still necessary, but which are not causing problems. These should be revisited and removed if they aren’t needed anymore!

• This bit with the tornado.access logger no longer seems to be necessary:

  web-monitoring-diff/web_monitoring_diff/server/server.py

  Lines 44 to 46 in 0abd10f

  	# Tornado logs any non-success response at ERROR level, which Sentry captures
  	# by default. We don't really want those logs.
  	sentry_sdk.integrations.logging.ignore_logger('tornado.access')

• We should probably enable or have a way to enable tracing! This would be really useful performance telemetry.

• Sentry now has a logs feature, should we still be using breadcrumbs?

  web-monitoring-diff/web_monitoring_diff/server/server.py

  Lines 618 to 623 in 0abd10f

  	sentry_sdk.add_breadcrumb(category='request', data={
  	'url': self.request.full_url(),
  	'method': self.request.method,
  	'headers': headers,
  	})
  	sentry_sdk.add_breadcrumb(category='response', data=response)

[bhushangitfull]

WIP, working on this

[bhushangitfull]

Sentry's manual capture_exception in write_error may be redundant

[bhushangitfull]

The write_error method in server.py manually calls scope.capture_exception() for HTTPError 500s (line 599)with this comment: "Instances of PublicError and tornado.web.HTTPError won't get tracked by Sentry by default".
However, testing with the current Sentry SDK shows that the Tornado integration now auto-captures these errors automatically even without the manual block. The before_send hook confirms the capture happens via "type": "logging" mechanism.
The manual block may now be safely removed. This should be verified against the ignore_logger('tornado.access') line as well, which was added for a similar reason.