Fix memory leak in HkdfStreamingPrf

[behrooz-stripe]

Repetitive calls to prf.compute() cause a memory leak. For example the following toy app will drain memory quickly:

public class Main {
  public static void main(String[] args) throws GeneralSecurityException, IOException {
    System.out.println("Starting..." + ProcessHandle.current().pid());
    String secretRawString = "...a sample HkdfPrfKey..."
    PrfConfig.register();
    KeysetHandle tinkHandle = CleartextKeysetHandle.read(JsonKeysetReader.withString(secretRawString));
    for (Long i = 0L; i < 1_000_000_000L; i++) {
      PrfSet prf = tinkHandle.getPrimitive(PrfSet.class);
      prf.computePrimary(i.toString().getBytes(), 32);
    }
    System.out.println("Done. Press any key to exit...");
    System.in.read();
  }
}

this is because in HkdfInputStream class, the allocated ByteBuffer is a direct buffer vs. a heap buffer. Direct buffers are allocated "by calling through to native OS allocs, bypassing the standard JVM heap... memory-storage areas of direct buffers are not subject to garbage collection because they are outside the standard JVM heap." See here for more info.
Now the question might be the capacity is set to zero (buffer = ByteBuffer.allocateDirect(0);) however the overhead involved the pointer itself adds up on MANY calls. This basically means repetitive calls to prf.compute are same as this toy app:

public class Main {
  public static void main(String[] args) {
    System.out.println("Starting..." + ProcessHandle.current().pid());
    for (Long i = 0L; i < 1_000_000_000L; i++) {
      ByteBuffer byteBuffer = ByteBuffer.allocate(0);
      byteBuffer.mark();
    }
    System.out.println("Done. Press any key to exit...");
  }
}

Which sure enough will drain memory in matter of seconds. In practice since prf compute takes more time and is not called in such aggressive for loops; the leak is a lot slower and harder to notice. In our application, we had many repetitive calls resulting in an eventual drainage of machine memory. I have run these apps under a memory profiler and have confirmed the same findings. Stacktrace:

	at jdk.internal.misc.Unsafe.allocateMemory0(java.base@17.0.14/Native Method)
	at jdk.internal.misc.Unsafe.allocateMemory(java.base@17.0.14/Unsafe.java:630)
	at java.nio.DirectByteBuffer.<init>(java.base@17.0.14/DirectByteBuffer.java:125)
	at java.nio.ByteBuffer.allocateDirect(java.base@17.0.14/ByteBuffer.java:332)
	at com.google.crypto.tink.subtle.prf.HkdfStreamingPrf$HkdfInputStream.initialize(HkdfStreamingPrf.java:88)
	at com.google.crypto.tink.subtle.prf.HkdfStreamingPrf$HkdfInputStream.read(HkdfStreamingPrf.java:129)
	at com.google.crypto.tink.subtle.prf.PrfImpl.readBytesFromStream(PrfImpl.java:45)
	at com.google.crypto.tink.subtle.prf.PrfImpl.compute(PrfImpl.java:67)
	at com.google.crypto.tink.prf.PrfSet.computePrimary(PrfSet.java:44)
...

The fix is simply to swap allocateDirect with allocate which is heap managed and garbage collected. I've verified the fix does indeed solve the leak.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[behrooz-stripe]

I guess this doesn't auto close but merged via this commit.