Add JNI code for ed25519-zebra

[droark]

Add some code allowing other languages, via JNI, to interact with ed25519-zebra. The initial commit:

• Allows users to obtain a random 32 byte signing key seed.
• Allows users to obtain a 32 byte verification key from a signing key seed.
• Allows users to sign arbitrary data.
• Allows users to verify an Ed25519 signature.
• Includes a Java file that can be used.
• Includes some Scala-based JNI tests.

[droark]

@yaahc - Folded in your requested changes. The build system might not be fully optimized, though. I noticed that libed25519jni.a and libed25519jni.{so/dylib} appear in both target/{mode} and target/{mode}/deps. Is there a way to get those files to appear only once? I'm assuming it's something subtle that I missed.

Thanks.

[droark]

@yaahc - Pushed some more build system changes. They partially undid your requested changes, such as removing the workspace. If you think it's worthwhile to put that back, I'm happy to discuss it. Things are fine on my end but I don't mind moving things around if they'll improve things or fit standard Rust patterns.

[yaahc]

@yaahc - Pushed some more build system changes. They partially undid your requested changes, such as removing the workspace. If you think it's worthwhile to put that back, I'm happy to discuss it. Things are fine on my end but I don't mind moving things around if they'll improve things or fit standard Rust patterns.

oh, so you removed the workspace but didn't add back the .cargo/config. That's probably fine, just need to be careful to make sure our CI still runs the tests in the subcrate. Out of curiosity what was the issue with the workspace that led you to remove it?

[droark]

@yaahc - I'm a little confused. I was under the impression that .cargo/config wasn't necessary. It also seemed to be messing with the path within the target directory.

Regarding why it was added in the first place, it's a bit of cruft. At first, the Java and the Rust code were basically sitting on top of each other. The config file got added in order to have a place where target files could go. Once everything got separated and worked out on my end, the file didn't seem to be necessary anymore. If it's causing CI problems, I can definitely reassess.

[yaahc]

@yaahc - I'm a little confused. I was under the impression that .cargo/config wasn't necessary. It also seemed to be messing with the path within the target directory.

Oh, you're right, it isn't necessary. I thought you'd used it to deduplicate the target/ directory between the inner and the outer crate so they can share compilation artifacts. This is why I suggested switching to a workspace, because one of the features of a workspace is that all crates in the workspace share a single target directory. So when you removed both I was confused because I assumed this would cause issues with target/ directories for you that had been a problem before, but it seems that is not the case, so it's fine.

Regarding why it was added in the first place, it's a bit of cruft. At first, the Java and the Rust code were basically sitting on top of each other. The config file got added in order to have a place where target files could go. Once everything got separated and worked out on my end, the file didn't seem to be necessary anymore. If it's causing CI problems, I can definitely reassess.

👍

[droark]

@yaahc - Okay, I think we're finally golden. :) The last 2-3 commits should be all that you need to review but I understand if you want to review the whole thing again. My apologies for always adding stuff. This should be it for awhile.