Unmarshal subproblems from problem details

[mbaynton]

Fixes golang/go#38978

[gopherbot]

This PR (HEAD: fc07adf) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/crypto/+/233166 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

[gopherbot]

Message from Gobot Gobot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/233166.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Mike Baynton:

Patch Set 1:

Looks like Roland and I both wrote patches for this at the same time. Adding Roland as a reviewer on mine. Looking at Roland's, they seem functionally about the same. Differences are I got a bit more liberal with reorganizing the Error/Problem types. This way what problem details look like is only described once, and there are types whose names directly correlate to RFC Problem Details / Subproblems. The downside is a tiny BC break in that by embedding ProblemDetails in Error, if someone was making their own acme.Error instances outside the package using struct literals, it would no longer compile (as seen in the modifications to types_test.go)

I also added another not-unmarshaled field from RFC 7807, title. I don't think Boulder sets it but that's a bit Boulder-centric. (And I would love if someday it did! ;))

I did leave out subproblems when stringing Error but maybe we should. In practice it is rare for one order to generate tons of subproblems/a huge error string.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/233166.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Roland Shoemaker:

Patch Set 1:

(4 comments)

Happy to defer to your CL. I've left a few structural/content comments.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/233166.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

Message from Mike Baynton:

Patch Set 1:

(4 comments)

Patch Set 1:

(4 comments)

Happy to defer to your CL. I've left a few structural/content comments.

Thanks for the review! And cool, I do appreciate the contribution opportunity. Pushing changes now.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/233166.
After addressing review feedback, remember to publish your drafts!

[gopherbot]

This PR (HEAD: 3a0a8e9) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/crypto/+/233166 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

[gopherbot]

Message from Go Bot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

---

Please don’t reply on this GitHub thread. Visit golang.org/cl/233166.
After addressing review feedback, remember to publish your drafts!