Added healthy flag to ConnectionPool

[gshively11]

Branched from #808, as those changes are critical for us. We can rebase/resubmit another PR if/when #808 is merged.

• ConnectionPool starts out as healthy
• If the internal pools connections drop to 0, and a createPool call
  fails, then the ConnectionPool will be flagged as unhealthy (healthy =
  false)
• If an unhealthy ConnectionPool is able to successfully call
  createPool, then the ConnectionPool will be reflagged as healthy
  (healthy = true)
• This allows applications to decide how to deal with unhealthy
  ConnectionPools (recreate, check for new config, failover, etc).

[dhensby]

I like this healthyPool flag and I think it's implemented well.

[willmorgan]

Logic sounds great! 👍

[gshively11]

I should get back on track with this tomorrow

[dhensby]

@gshively11 I've rebased this for you on top of the latest 6.0 work. I've also implemented the feedback and updated the changelog

[gshively11]

Appreciate the help! Small piece of feedback though, the force pushing makes things a little rough for collaboration. If squash+merge is used when merging PRs, the history in the PR can be messy and thus doesn't need a force push on the PR branch.

Will test out the changes here shortly...

[dhensby]

Thanks for the feedback. My approach is never to squash + merge because you loose the meaningful history of the PR. The PR branches are free for history re-writing because they are a candidate to go in and should be in as clean a state as possible at merge time.

If someone's re-written history on a shared branch you can tell by running a git fetch and then seeing if you're in a diverged state. simply git reset origin/[branchname] to get back in-line and on you go.

Your work was also based on commits that were written out of history so it couldn't have gone in without a rebase anyway or we'd have merged in a bunch of bad commits.

[gshively11]

Cursory tests look good, now I need to write up an integration test suite for making sure the healthy/failover detection works in our wrapper, but I think this should be good to merge.

Re: the squash + merge, difference in philosophy I guess, no biggie. I like master having a clean, 1 commit per PR merge, and then you can always go look at the PRs for the detailed, unsquashed history, so you're never really losing the history of the PR. If you force-push/rebase in the PR, you're technically losing the history of the evolution of the PR.

[dhensby]

Cursory tests look good, now I need to write up an integration test suite for making sure the healthy/failover detection works in our wrapper, but I think this should be good to merge.

great, you'll need the take the PR out of draft mode - I can't seem to do that!