Refactor encrypt interface and various TS types

[CDThomas]

Changes:

• Combine plaintext, columnName, tableName, and lockContext args into a single opts object for encrypt
  • The opts type, EncryptPayload, is shared between encrypt and encryptBulk
• Return JS objects from encrypt/encryptBulk instead of strings
• Make encryptSchema arg for newClient required
  • This was already the behaviour on the Rust side, but now the types match the behaviour
• Make the table property passed to encrypt and encryptBulk required
  • This was already the behaviour on the Rust side, but now the types match the behaviour
• Remove unused EncryptedEqlPayload and BulkEncryptedEqlPayload types
• Push logic for handling undefined cstTokens from TS to Rust
• Add integration tests for encryptBulk and decryptBulk
• Add integration tests for passing in undefined for ctsToken

[CDThomas]

plaintext, columnName, tableName, and context have been combined into a single arg of type EncryptPayload. encrypt takes a single EncryptPayload and encryptBulk takes an EncryptPayload[].

Is this similar to what you had in mind @calvinbrewer? I can do something similar for decrypt/decryptBulk as well if that's helpful (but we'd only be combining ciphertext and lockContext into a DecryptPayload.

[CDThomas]

This is the change that fixes up errors on the Rust side when the token from JS is undefined.

[calvinbrewer]

I'm a bit confused on what you are doing with the index.cts file. Based on my understanding of the neon framework, we have to explicitly define the functions and types in the module definition in order to support TypeScript in this package.

E.g.

export type argTypes {
  ...
}

export function encrypt(args: argTypes) {
  return addon.encrypt(args)
}

You left the decrypt function in there so I'm just confused on your direction!

[CDThomas]

I'm a bit confused on what you are doing with the index.cts file. Based on my understanding of the neon framework, we have to explicitly define the functions and types in the module definition in order to support TypeScript in this package.

E.g.

export type argTypes {
  ...
}

export function encrypt(args: argTypes) {
  return addon.encrypt(args)
}

You left the decrypt function in there so I'm just confused on your direction!

@calvinbrewer, my intent is to leave the types defined in the declare module './load.cjs' block, so TypeScript types should still work. I'm removing the wrapper functions in indext.cts because they looked to be a workaround for optional args not being handled properly on the Rust side. I still need to update decrypt to handle optional args on the Rust side, so I haven't removed the wrapper function, yet, but my intent is to do that (potentially in a follow up PR).

TypeScript types show up properly for me in the integration tests, but we can confirm in Protect.js as well before merging this PR.

Part of the purpose of the integration tests is to be able to be able to pick up on typing issues before testing things out in Protect.js.

[calvinbrewer]

I'm a bit confused on what you are doing with the index.cts file. Based on my understanding of the neon framework, we have to explicitly define the functions and types in the module definition in order to support TypeScript in this package.
E.g.

export type argTypes {
  ...
}

export function encrypt(args: argTypes) {
  return addon.encrypt(args)
}

You left the decrypt function in there so I'm just confused on your direction!

@calvinbrewer, my intent is to leave the types defined in the declare module './load.cjs' block, so TypeScript types should still work. I'm removing the wrapper functions in indext.cts because they looked to be a workaround for optional args not being handled properly on the Rust side. I still need to update decrypt to handle optional args on the Rust side, so I haven't removed the wrapper function, yet, but my intent is to do that (potentially in a follow up PR).

TypeScript types show up properly for me in the integration tests, but we can confirm in Protect.js as well before merging this PR.

Part of the purpose of the integration tests is to be able to be able to pick up on typing issues before testing things out in Protect.js.

Sounds good - let's do a pre release and test it out in Protect.js!

[CDThomas]

I'm a bit confused on what you are doing with the index.cts file. Based on my understanding of the neon framework, we have to explicitly define the functions and types in the module definition in order to support TypeScript in this package.
E.g.

export type argTypes {
  ...
}

export function encrypt(args: argTypes) {
  return addon.encrypt(args)
}

You left the decrypt function in there so I'm just confused on your direction!

@calvinbrewer, my intent is to leave the types defined in the declare module './load.cjs' block, so TypeScript types should still work. I'm removing the wrapper functions in indext.cts because they looked to be a workaround for optional args not being handled properly on the Rust side. I still need to update decrypt to handle optional args on the Rust side, so I haven't removed the wrapper function, yet, but my intent is to do that (potentially in a follow up PR).
TypeScript types show up properly for me in the integration tests, but we can confirm in Protect.js as well before merging this PR.
Part of the purpose of the integration tests is to be able to be able to pick up on typing issues before testing things out in Protect.js.

Sounds good - let's do a pre release and test it out in Protect.js!

@calvinbrewer I have a branch up in Protect.js that demonstrates the new types in this PR (released as v0.13.0-0) are working. Here's an example of errors from tsc that show that the types for protect-ffi functions get picked up (and aren't defaulting to any).

[calvinbrewer]

Should we lift this logic in Protect.js to this repo? https://github.com/cipherstash/protectjs/blob/main/packages/protect/generateEqlSchema.ts

Then leverage the EqlSchema upstream?

[CDThomas]

Nice. Yes, I like that approach. Let's add that in a follow-up PR.

[calvinbrewer]

Nice this is working well and validated typing is working as expected here: cipherstash/stack@5e12152