## Problem
Currently, even if `LAMBDA_REMOTE_DOCKER=1`, we unzip the zip files in the directory they are in, which is usually /var/lib/localstack, which usually has a bind mount to the host.
On docker desktop, due to the use of grpc-FUSE (on macos), this can be very slow, about 200 times slower than on volumes / directly on the host. With experimental virtio filesystem enabled (also on macos), this can be reduced to about 30 times as slow, but still problematic.
This means a lambda may take a lot of time processing, for each additional layer some more. This especially affects nodejs lambdas with huge node_modules folders.

## Probable solution
At least if `LAMBDA_REMOTE_DOCKER=1`, we should leave the initial zip files on the bind mount (for persistence etc), but the working directories after unzipping should be located on non-bind mounts, to speed up the IO for unzipping.
(
                'Unable to find executor for Lambda function "%s". Note that '
                + "Node.js, Golang, and .Net Core Lambdas currently require LAMBDA_EXECUTOR=docker"
            )
            % lambda_name
        )
    lambda_name = lambda_function.name()
    arn = lambda_function.arn()
    runtime = get_lambda_runtime(lambda_function)
    lambda_environment = lambda_function.envvars
    handler_name = lambda_function.handler = lambda_function.handler or LAMBDA_DEFAULT_HANDLER
    code_passed = lambda_function.code
    is_local_mount = code_passed.get("S3Bucket") == config.BUCKET_MARKER_LOCAL
    
    LAMBDA_EXECUTOR.cleanup(arn)
    
    _result = store_and_get_lambda_code_archive(lambda_function)
    if not _result:
        return
    lambda_cwd, archive_file, zip_file_content = _result
    
    lambda_handler = generic_handler
    is_java = lambda_executors.is_java_lambda(runtime)
    if is_java:
        
        
        
        try:
            lambda_handler = get_java_handler(
                zip_file_content, archive_file, lambda_function=lambda_function