just suggestions, but overall looks fine

Added D6824 as parent, but this looks good.

We also need to do the other half of this on the client side

Rebase on master

Rebase on master

Rebase on master

Rebase on master

Apply JS promise feedback

Apply proto changes to keyserver addon

Remove response enum, as it duplicates GRPC behavior

going to ask for another review, as this has significantly changes since it was accepted

Since the generated bindings require me to send Result<tonic::Response<DeleteUserResponse>, tonic::Status>, I can only send a status. I will just remove the inner result and let the grpc status dictate success.

Keep JNI code as part of comm_jni_module

I plan on improving this anyway, looks good for now.

Add grpc implementation as it's not that much code

Most of my concerns will be a non-issue if we every write the cli parsing in rust.

Looks fine, probably a few ways to remove a lot of the boiler plate, but we can do that later.

Forced call to getRustAPI() on master, asserted it was broken, patch this in, and fixed the call.

Going to go back to the drawing boards for this. We should really be separating out the JNI code so that it's part of the existing comm_jni_module (e.g. native/android/app/CMakeLists.txt), and the code held in native/cpp/CommonCpp can just contain non-JNI C++ code. This would allow for us to avoid doing the System.loadLibrary() call, needing to make a shared library, and linking against numerous libraries (e.g. fbjni).

Update TOC

Apply feedback from D6725

As for "shared workflows"... I agree it might be a little ambiguous, but I'm not sure what a better term would be, and am hoping it won't be so confusing since people will get to it from the mainline

Do we need to clone client and config so often? I'm assuming that config would be relatively static after creation. And some of the client clones seem to be unnecessary as they seem to fall out of scope from both scopes after their use.

I don't really see anything in ENG-2906 that explains why we're trying to remove domain-specific terms here. Given that the purpose of this section is to explain how Nix introduces dependencies, I feel like it's fine as is? Defer to @ashoat

Use titles instead of command names for package managers

Apply feedback

@ashoat asked me to just initially copy the existing documentation when applicable (this diff), then reword as necessary in another diff ( D6726 in this case).

A lot of these questions would better suited for the person who created the original structure of cpp/CommonCpp. The CMake structure largely just inherits the structure of the directories as there's a similar separation of concern.

I had already done the work in my attempt to get the jni working for the native modules

Whitespaces next to :: is a valid Rust syntax. It must be valid to accept newlines and tabs when splitting very long expressions.

Need to compile the .so's for the native libraries, then make their symbols available to jni with system.loadLibrary()

I'll defer to bartek on tracing

Apply feedback, rebase on master

Remove obsolete references to folly dependencies

No reviewers?