Fixes #13802
Fixes #21140

Summary of changes

• Removed even-better fork of good
• Updated all route handlers to use async/await rather than the reply callback
• Updated changes to server.auth calls
• Upgrade hapi, joi, wreck, h2o2, hapi-auth-cookie, inert, vision, boom
• Added new validation failAction handler that returns errors similar to Hapi v14
• Changes to how we use exports from joi
• Reimplemented monitoring built on good. This time around, I'm going to push to get it accepted into the mainline package so we don't have to maintain a fork. PR here: Allow reconfiguring after monitor is started hapijs/good#593
• Made subtle changes to how security plugin interacts with Hapi

Risks

As with any major upgrade, this PR has risks for breakage across the entire application. While I have made sure to pay attention to all these areas, it's possible I've missed things. Areas we may want to focus on in QA:

• Validation errors. Any features that depend on the backend telling us that the frontend sent valid data should be checked. In particular how the error message is displayed may be broken in some areas. I believe I was able to get this to be exactly the same before, but it's possible some subtle thing was missed.
• Authentication. This upgrade changes how we tell Hapi who the authenticated user is. We should validate that nothing about this behavior is wrong.
• Logging. I have upgraded our core logging components in the legacy platform. I don't anticipate any major problems here.
• Kibana Monitoring. For similar reasons, our monitoring of Kibana itself may have changed slightly. I have done my best to verify that we're sending the same data to ES for kibana's internal monitoring, but it's possible it's not quite right or misbehaves in bad conditions.

Potential Areas for Improvement

• In order to have the same validation errors return from our backend as we did in Hapi v14, we have to install a default validation failAction handler. This means that any tests that don't set up their test server with this handler will not have the same validation responses as the real environment does. It would be a nice improvement if we had a single test server fixture that we used everywhere.

Release notes

release-note: The Hapi framework has been upgraded from v14.2.0 to v17.5.3. There are a number of breaking changes affecting plugins that register custom backend routes. The reply callback interface for supplying responses has been replaced with an async/await interface and a response toolkit. More details in the Hapi upgrade guide

Dev Docs

Upgraded Hapi framework for plugin backend endpoints

The Hapi framework has been upgraded from v14.2.0 to v17.5.3. There are a number of breaking changes affecting plugins that register custom bacekend routes. This does not affect plugins that do not have backend routes.

The reply callback interface for supplying responses has been replaced with an async/await interface and a "response toolkit". Example:

Before 6.5

server.route({
  path: '/myroute',
  handler(req, reply) {
    getSomeData().then((data) => reply(data));
  }
});

server.route({
  path: '/myredirect',
  handler(req, reply) {
    reply.redirect('/otherroute');
  }
});

After 6.5

server.route({
  path: '/myroute',
  async handler(req, h) {
    return await getSomeData();
  }
});

server.route({
  path: '/myredirect',
  handler(req, h) {
    return h.redirect('/otherroute');
  }
});

More details can be found in the Hapi upgrade guide.