bindings/blst.{hpp,swg}: shift memory management to JVM GC.

[dot-asm]

So far Java interface was reliant on deprecated finalize() method to
free memory allocated by blst. Now we use Java long[] as opaque
storage for blst structures.

@Nashatyrev, @cemozerr, could you have a look at this? Not necessarily at C++ part, as main question is if auto-generated .java code is sensible. In other words, execute bindings/java/run.me and skim through newly created bindings/java/*.java. Please:-)

[Nashatyrev]

Hey @dot-asm !
That's totally cool! Especially taking into account that in Teku we may keep hundreds of thousands of Pubkeys in memory.

Java part looks good to me.

Some comments:

• What's different with Pairing? Is it still left to be deleted manually (or with finalize())? Not a big deal though since these are kind of temporary objects and are deleted explicitly.
• There public blstJNI.delete_* methods are still generated which do the following:

  arg1 = (blst::SecretKey *)JCALL(GetLongArrayElements, jarg1, 0);
  delete arg1;

which I think would definitely cause SIGSEGV. I see that they are not invoked anymore from other classes however it would be safer to remove them totally

• (codestyle nit not directly related to this PR) there are methods like class P1 { P1 add(P1 a); } which modify and return this instance. From my perspective they could be erroneously interpreted as that a new instance is returned and this instance is left unmodified. Not sure about common C++ patterns, but Java dev would likely misinterpret this. Does it make sense to return void from these methods to avoid such misuse?

[dot-asm]

• What's different with Pairing? Is it still left to be deleted manually (or with finalize())? Not a big deal though since these are kind of temporary objects and are deleted explicitly.

No class has finalize or delete methods, including Pairing. You don't have to explicitly delete anything anymore. The only thing special about Pairing is that allocated size depends even on DST. But garbage collector doesn't care...

• There public blstJNI.delete_* methods are still generated which do the following:

  arg1 = (blst::SecretKey *)JCALL(GetLongArrayElements, jarg1, 0);
  delete arg1;

which I think would definitely cause SIGSEGV. I see that they are not invoked anymore from other classes however it would be safer to remove them totally

Unfortunately I haven't found a way to suppress them [yet]. As you correctly point out, blstJNI.delete-s are not called from generated .java code, and application is not supposed to call blstJNI directly. This is considered tolerable [for now].

[I'll respond to 3rd bullet point separately.]

[Nashatyrev]

No class has finalize or delete methods, including Pairing

Oh right, sorry! Probably opened older Pairing.java version

[dot-asm]

Unfortunately I haven't found a way to suppress them [delete methods]

Fixed.

[dot-asm]

It's committed now. Just in case, if you get "disaster" exception after git pull, it means that your ../libblst.a is stale. Delete it and re-run.me.

[dot-asm]

[I'll respond to 3rd bullet point separately.]

I've created separate #57 to address this.