Implement EdDSA Signer

[Slamdunk]

Hope to see this in 4.1.0 release

[lcobucci]

@Slamdunk this looks quite good, thanks 👍

I've got a few small requests, though 😬

[Slamdunk]

Ed25519 is awesome, among the asymmetric signing is the fastest, and its keys are so easy to store and generate:

+-------------+-----------+
| benchmark   | diff      |   
+-------------+-----------+
| Sha384Bench | 460.14x   |   
| Sha384Bench | 892.40x   |   
| Sha256Bench | 459.90x   |   
| Sha256Bench | 764.18x   |   
| Sha512Bench | 466.50x   |   
| Sha512Bench | 957.14x   |   
| EddsaBench  | 123.00x   |   
| EddsaBench  | 303.83x   |   
| NoneBench   | 1.00x     |   
| NoneBench   | 1.17x     |   
| Sha384Bench | 5,163.65x |
| Sha384Bench | 313.29x   |   
| Sha256Bench | 5,258.72x |
| Sha256Bench | 383.07x   |   
| Sha512Bench | 5,492.08x |
| Sha512Bench | 312.46x   |   
+-------------+-----------+

[Slamdunk]

I've used InvalidKeyProvided exception but not its factory methods because SodiumException has much wider scope range

[lcobucci]

We could introduce a named constructor there but this works too.

[lcobucci]

@Slamdunk I'm just wondering about the optional dependency on sodium... Do you have anything against just requiring it?

We added mbstring requirement in the past (which is only there for ECDSA), so the precedent is there.

Apart from that, sodium is pretty stable and works really well - I have it enabled in most of the projects I work.

That would allow for us to remove the checks and move the "breakage" to build time instead of runtime.

I had the idea in the past to break the signers into satellite repositories but that creates more complexity for very little benefit.

What's your take?

[Slamdunk]

I had the idea in the past to break the signers into satellite repositories but that creates more complexity for very little benefit.

Sub-packages are a good idea for non-core features that require external libraries, you don't want to be slowed down in the mainline by a dependency.
However, extensions are always ready when a new PHP version is ready, so you're not slowed down by them, so features that require them can make into main-package.

I'm just wondering about the optional dependency on sodium... Do you have anything against just requiring it?

No: often maintainers prefer PR that do not force anything to users, so I went with a runtime check, since we haven't had a prior discussion.

Here comes the updated push

[lcobucci]

@Slamdunk I just rebase to add the GPG signature on commits and tidy the history a bit. Will merge once CI is done.

Thanks a lot!