http-01: refactor provider for presenting token

[jehiah]

This implements the last suggestion from #32 by @janeczku to separate solving the http-01 challenge, from making the keyAuth available at the appropriate path.

This change creates a new interface

type HTTPChallengeProvider interface {
    PresentToken(domain, path, keyAuth string) error
    CleanUp(domain, path string)
}

And a httpChallengeServer (extracted from httpChallenge) which implements that interface and is used by Client.

I am looking to use lego as a library to generate certs and will need to have my own logic for making the token available, so the suggestion in #32 was quite useful.

@xenolf If you have any thoughts on this change (or suggestions on impelemtnation) i'm all ears.

[xenolf]

Hey there :)
Thank you for your contribution!

The change in itself looks sound. What I'm thinking about at the moment is though if it would make sense to have a general interface to all challenges along this implementation.
We will need something like this for DNS-01 and TLS-SNI-01 as well. Some discussion about this is going on in #36.

[jehiah]

@xenolf can you take another look. This incorporates feedback from #36 and exports a generic interface which (i think) will work for all challenges.

type ChallengeProvider interface {
    Present(domain, token, keyAuth string) error
    CleanUp(domain string)
 }

Then there is a un-exported https and tls provider (ie: the http/tls servers that are the default providers for this package), and an exported function to set a custom providers, and exported helpers build the path for the http-01 challenge, and the cert for the tls-sni-01 challenge.

I'm of the opinion that this package should not export ProvidersOpts (as mentioned in #36) as that is a concept that concrete implementations need to care about; this package just exports the interface any provider needs to implement to be callable by the appropriate challenge setup/teardown before the solver is run.

I've tried to keep things named consistently, but if you have better naming suggestions on anything, just comment. I'm also happy to apply this refactoring to the dns provider when that lands in master

[jehiah]

@xenolf I see you've started landing support for dns-01 challenge in master. I've rebased this and applied the same ChallengeProvider interface to the DNS code contained within. I'm not perfectly confident my changes are perfect as i don't have a test setup for the three DNS providers that are currently implemented, but i look forward to your feedback either way.

[xenolf]

I think when going down this route we should export constants for these identifiers. Like acme.HTTP01.

[jehiah]

good idea; update forthcoming

[jehiah]

resolved

[xenolf]

I think those should be consts.

[jehiah]

@xenolf let me know if you have any other feedback here, or if you'd like me to squash what's here for merge.

[xenolf]

Nah I think I'm happy now ;)
Squash it and I'll merge it in.

[jehiah]

squashed

[coveralls]

Changes Unknown when pulling 617dd4d on jehiah:custom_http_challenge_76 into ** on xenolf:master**.