Expose AccountCredentials::private_key()

[djc]

Fixes #197. @cpu what do you think, is this misuse-resistant enough? I like how long we've been able to get buy with just AccountCredentials serialization, but I guess it is a bit of "security" by obscurity. Given that this is clearly labeled as private_key() (unless you've got better name suggestions) and yields the PrivateKeyDer type (and only a reference at that), seems like this might be okay?

[notABot101010]

One minor inconsistency (which probably warrants its own issue) is that this method exposes PrivateKeyDer while AccountBuild::from_parts accepts a PrivatePkcs8KeyDer which is counterintuitive as we may expect the "export side" to give a more specific type (PrivatePkcs8KeyDer), and the "import side" to accept, maybe, a more generic type (PrivateKeyDer).

It might be nice to use the same type everywhere and maybe this PR could benefit from changing the type of AccountCredential.key_pkcs8 (and thus also of this getter) to the more specific PrivatePkcs8KeyDer.

Otherwise +1 for me.

Regarding the misuse-resistance, I understand the idea behind, but opaque types unfortunately directly clash with interoperability (with other programming languages for example).

[djc]

One minor inconsistency (which probably warrants its own issue) is that this method exposes PrivateKeyDer while AccountBuild::from_parts accepts a PrivatePkcs8KeyDer which is counterintuitive as we may expect the "export side" to give a more specific type (PrivatePkcs8KeyDer), and the "import side" to accept, maybe, a more generic type (PrivateKeyDer).

That's fair -- added a commit to make the API more consistent.

[cpu]

I think it's a reasonable addition and the sensitivity is obvious enough from the name. 👍

[djc]

Released as 0.8.3.