Ease interpretation of errors that arise during registration operations

[seh]

At present, the following functions return type error:

• EurekaConnection.RegisterInstance
• EurekaConnection.ReregisterInstance
• EurekaConnection.DeregisterInstance

They can fail for many reasons, but a few stand out:

• DeregisterInstance fails if the instance does not exist (HTTP status code 404).
• DeregisterInstance fails if the instance did exist (HTTP status code 200).
  This is due to expecting status code 204, even though the Eureka documentation promises status code 200 for a successful deletion. This mismatch makes me wonder if anyone else is using this method.

To work around these problems, I had to write the following function to filter errors that arise when calling DeregisterInstance:

func deregistrationFailureIsInnocuous(err error) bool {
    msg := err.Error()
    return strings.Contains(msg, "200") || strings.Contains(msg, "404")
}

That is clear evidence of a gap in the interface.

Both ReregisterInstance and RegisterInstance can fail with status code 400 if Eureka deems the instance payload invalid. Note that it's not possible for registration to fail due to a collision with an existing instance with the same ID; Eureka replaces the existing registration.

It would be helpful for callers to be able to discern why these operations failed. Rather than introducing sentinel error values or types, I propose that we introduce a few exported functions:

• InstanceWasMissing(error) bool
  True for failures in DeregisterInstance due to receiving status code 404
• InstanceWasInvalid(error) bool
  True for failures in RegisterInstance and DeregisterInstance due to receiving status code 400

Do you have counter-proposals for these names? Are there other functions you can think of that would clarify what went wrong?

[seh]

I noticed that fargo already exports type AppNotFoundError. I'd rather not repeat that technique here.

[seh]

See this gist (errors.go) for an adaptation of the interpretive predicate functions I had proposed in #47. You can see that the caller still has consider which operation he had attempted in order to know which function to call, due to Eureka's irregular treatment of metadata updates, but it beats parsing the error messages.

If you change your mind about whether fargo should include these or similar predicates, we can open another issue.