Packet-based enc/dec cipher streams

[albertzaharovits]

This adds a new bare snapshot repository project which contains the classes implementing encryption (and decryption) input stream decorators that support mark and reset.

Relates #48221 , #46170

Edit:
Extract from javadocs explaining how encryption works:

An {@code EncryptionPacketsInputStream} wraps another input stream and encrypts its contents.The method of encryption is AES/GCM/NoPadding, which is a type of authenticated encryption. The encryption works packet wise, i.e. the stream is segmented into fixed-size byte packets which are separately encrypted using a unique {@link Cipher}. As an exception, only the last packet will have a different size, possibly zero. Note that the encrypted packets are larger compared to the plaintext packets, because they contain a 16 byte length trailing authentication tag. The resulting encrypted and authenticated packets are assembled back into the resulting stream. The packets are encrypted using the same {@link SecretKey} but using a different initialization vector. The IV is 12 bytes wide and it's comprised of an integer {@code nonce}, the same for every packet in a stream, but which MUST not otherwise be repeated for the same {@code SecretKey} across other streams, and a monotonically increasing long counter. When assembling the resulting stream, the IV is prepended to the corresponding packet's ciphertext.
The packet size is preferably a large multiple of the AES block size (128 bytes), but any positive
integer value smaller than {@link EncryptedRepository#MAX_PACKET_LENGTH_IN_BYTES} is valid.
This input stream supports the {@code mark} and {@code reset} operations, but only if the wrapped stream supports them as well. A {@code mark} call will trigger the memory buffering of the current packet and will also trigger a {@code mark} call on the wrapped input stream on the next packet boundary. Upon a {@code reset} call, the buffered packet will be replayed and new packets will be generated starting from the marked packet boundary on the wrapped stream.
The {@code close} call will close the encryption input stream and any subsequent {@code read},
{@code skip}, {@code available} and {@code reset} calls will throw {@code IOException}s.
This is NOT thread-safe, multiple threads sharing a single instance must synchronize access.

and how decryption works:

A {@code DecryptionPacketsInputStream} wraps an encrypted input stream and decrypts
its contents. This is designed (and tested) to decrypt only the encryption format that
{@link EncryptionPacketsInputStream} generates. No decrypted bytes are returned before
they are authenticated.
The same parameters, namely {@code secretKey}, {@code nonce} and {@code packetLength},
that have been used during encryption must also be used for decryption, otherwise
decryption will fail.
This implementation buffers the encrypted packet in memory. The maximum packet size it can
accommodate is {@link EncryptedRepository#MAX_PACKET_LENGTH_IN_BYTES}.
This implementation does not support {@code mark} and {@code reset}.
The {@code close} call will close the decryption input stream and any subsequent {@code read},
{@code skip}, {@code available} and {@code reset} calls will throw {@code IOException}s.
This is NOT thread-safe, multiple threads sharing a single instance must synchronize access.

[elasticmachine]

Pinging @elastic/es-security (:Security/Security)

[albertzaharovits]

Thank you for another thorough review @tvernum !
I have addressed all the issues you've pointed out. Please take another look.

[tvernum]

LGTM

[albertzaharovits]

@elasticmachine update branch