Plumb whereIn/whereNotIn through gRPC

[devinrsmith]

Additionally, removes WhereNotInTable and collapses logic into WhereInTable parameters.

Follow-up #3088

Fixes #990

[niloc132]

why explicit lock+unlock over computeLocked? at least as a reader the computeLocked is more concise, more obviously correct ("any chance that something could throw on the way out of lock() that would leave it locked, should we just do the lock inside the try/catch").

Example
io.deephaven.server.table.ops.JoinTablesGrpcImpl#create

        final Table result;
        if (!lhs.isRefreshing() && !rhs.isRefreshing()) {
            result = realTableOperation.apply(lhs, rhs, columnsToMatch, columnsToAdd, request);
        } else {
            result = updateGraphProcessor.sharedLock().computeLocked(
                    () -> realTableOperation.apply(lhs, rhs, columnsToMatch, columnsToAdd, request));
        }
        return result;

(could just as easily return from inside the if/else)

[devinrsmith]

I'm not a fan of lambda abstractions for singular operations (I see where the abstraction comes in handy for join where we have a lot of them), and the branching that results around the application. That said, the version I has has branching logic around the lock... something I personally prefer, but I think we can do better...

@rcaudy @niloc132 , would you be opposed to adding a new method to FunctionalLock:

public interface FunctionalLock extends Lock {
    ...
    default SafeCloseable closeableLock() {
        final SafeCloseableLock closeable = new SafeCloseableLock(this);
        lock();
        return closeable;
    }

This would allow the use of a try resource, which I think is much more ergonomic:

    @Override
    public final Table create(final WhereInRequest request, final List<SessionState.ExportObject<Table>> sourceTables) {
        ...
        try (final SafeCloseable _lock = lock(left, right)) {
            return request.getInverted() ? left.whereNotIn(right, columnsToMatch) : left.whereIn(right, columnsToMatch);
        }
    }

    private SafeCloseable lock(Table left, Table right) {
        return left.isRefreshing() || right.isRefreshing() ? updateGraphProcessor.sharedLock().closeableLock() : null;
    }

[rcaudy]

I don't hate it. Not a bad option, for cases where lambdas are annoying.

[niloc132]

One minor remark, discussed in slack also about getting js api bindings closer to working

[niloc132]

why a new idiom here, when we have one already?

[devinrsmith]

See commentary earlier for color - it's more concise and easier to read (and write) IMO.