elliptic-curve: remove ToString and FromStr impls

[newpavlov]

As discussed in #1598 users probably should prefer explicit serialization/deserialziation methods instead of using FromStr/ToString trait implementations.

FromStr implementations for ScalarPrimitive and NonZeroScalar are left unchanged since they have a symmetric Display impl. But note that the current FromStr impls for these types may be potentially confusing, since they decodes from hex, while FromStr impls for primitive numeric types decode from decimal encoding.

[tarcieri]

I would prefer to keep the FromStr/ToString impls FWIW, though they could perhaps be better documented

[newpavlov]

Personally, I find it strange that FromStr/ToString impls are gated on the pem feature. PEM encoding may be the most common one, but it's onIy one option and I don't think it's fit for user-facing interactions, i.e. it's extremely unlikely someone will input a PEM-encoded key manually or will display it to user.

Unfortunately, the docs are not clear enough about when FromStr should be and should not be implemented. I guess it's implied that it should be symmetric to ToString. But ToString is clearly tied to Display and I don't think it makes sense to implement Display for PublicKey and SecretKey.

Overall, I don't have a strong opinion here, so feel free to close this PR if you disagree with the position above.

[tarcieri]

PEM encoding is the main string encoding of these types humans are used to interacting with, IMO.

To me the reasons to prefer Display over ToString are because it integrates with the core::fmt subsystem, works on core, and avoids allocations. However in this case there isn't core::fmt::Formatter support for serializing PEM, only outputting a String, so any impl of Display would need to allocate a string anyway, which I think defeats the point.

There's an explicitness argument to be made for purpose-dedicated APIs, but FromStr and Display/ToString are easily discoverable.

[newpavlov]

PEM encoding is the main string encoding of these types humans are used to interacting with, IMO.

But I don't think we commonly use it to display keys to humans. It's just the traditional serialization format. And users certainly do not input PEM-encoded keys manually.

To me the reasons to prefer Display over ToString are because it integrates with the core::fmt subsystem

I think it's a misuse of the fmt subsystem. I agree that it would be nice to support alloc-less serialization, but it should be done using serialization into user provided buffers or with arrayvec-like types. Either way, it would require changes in the pem crate first.

My personal rule of thumb for whether an fmt::Display (and subsequently ToString) implementation is needed or not is whether it could be used with non-trivial formatting strings (i.e. anything besides "{}"). The PEM-based implementation IMO does not satisfy it.

Since I was not able to find good enough docs about it, I will try to ask for additional opinions about Display, FromStr, and ToString on URLO a bit later. Do you mind if I link this PR in it?

[tarcieri]

But I don't think we commonly use it to display keys to humans.

I think of PEM as the most common method of printing keys themselves, especially SPKI encoded public keys. Yes, it's a serialization format, but it's also pretty much the only game in town for providing a compact way of representing a key to the user as a string.

I will try to ask for additional opinions about Display, FromStr, and ToString on URLO a bit later. Do you mind if I link this PR in it?

Sure, that's fine

[newpavlov]

The URLO thread has only two replies, but I guess my opinion about the traits is comparatively on a more extreme side. I still think that we do not need the impls in this case and that users should use the explicit methods, but I am not strongly opposed to having the either, so I will close this PR.