Add Load Impact Automatic Performance Testing

[populist]

This is integration with Load Impact's V2 REST API. Once you figure a test in Load Impact and provide your API Key, Quicksilver will kick off a test and give you a URL at which you can review the results.

[joshkoenig]

@stevector Thanks for your comments. The vision is right on, but:

Of course Quicksilver as a whole is still evolving. And maybe for the stage we are at now we should be actively fighting (possibly) premature abstraction.

That's where we are at. Right now we need people to understand that they "own" their QS implementation. Either editing the code, or actively managing a secrets.json file accomplish this goal.

Going beyond that will likely mean taking things out of the Quicksilver Slace, e.g. native integration of external repos, slack, etc. Some of this is on the roadmap, and some of it is not, but the value should become clear as we see what people are doing more and more.

Secrets management is the one sticky wicket. We don't have a product answer on the roadmap, and demanding people use the key module may be setting too high a bar. We should discuss this more.

[stevector]

Thinking about this more, I'm less enthusiastic about evolving toward "Quicksilver Plugin" as a first class concept. QS can call Drush/WP-CLI and it can call Drupal/WordPress directly. Each already has their own plugin/module system. For use cases where DRY/abstraction is of high value (like the 100 sites question on today's couch coding) we can recommend encapsulating code in one of these more mature systems. And I think saying "use the Slack notifier contrib module/plugin" is better for us than building and maintaining Pantheon-native Slack notification.

Secrets management is tough, but at least it is not a QS-specific problem. Plenty of Drupal/WordPress sites just keep keys for external services as plain text in the DB, which carries a similar set of risks as committing them to a repo. This reminds me of the "product vs. practice" conversation we had a few months back when I was in the SF office. We don't necessarily need a Pantheon key management product as long as we point the way toward the generic best practice.