[completion] Filter completions on the server side

[benlangmuir]

Implement server-side code-completion filtering and limit the number of completion items to 200 results by default. This radically improves the performance of code-completion when there are a large number of results by avoiding the cost of serialization of lower priority results. We take advantage of LSP's isIncomplete flag to inform the editor that as the user types more characters it should re-query SourceKit-LSP for completions in case there are results that were previously filtered out that are now relevant to the new filter text.

I verified that server-side filtering is working in VSCode, Sublime Text, and vim (with coc.nvim). If any editors do not support isIncomplete yet, it is possible to disable server-side filtering.

Configuration

• By default, server-side filtering is enabled, and the maximum number of results is 200.
• You can override this using command-line options to sourcekit-lsp

sourcekit-lsp -completion-server-side-filtering=true -completion-max-results=200

• Alternatively, you can override this by passing initializationOptions to SourceKit-LSP during the initialize request:

"initializationOptions": {
    "completion": {
        "serverSideFiltering": true,
        "maxResults": 200
    }
}

• As an LSP extension, we also support passing completion options directly in the textDocument/completion request using the new parameter sourcekitlspOptions. This is intended mostly as a tool for experimentation and debugging.

Note: In the initial implementation, setting maxResults to unlimited (0 or nil) will have worse performance than if you disabled server-side filtering. We should be able to close that gap, but for now I don't recommend using large values for maxResults.

Implementation

When using server-side filtering, we keep track of a code-completion "session" for a given source file and completion location.

foo.barB|
    ^   ^
    |    ` cursor location
     ` start of identifier

In the above example, the completion session will be for the location after "." at the start of the identifier, and the completion location (usually the cursor location) determines what the "filter text" for the completion will be, in this case "barB".

Once we open a session, any subsequent completion requests that have the same location and use triggerKind == triggerFromIncompleteCompletions will efficiently re-filter the existing completions. If the new completion location is not compatible with the session, we return an error rather than recompute completions so that editors can rely on triggerFromIncompleteCompletions always being really fast. Currently, any other trigger kind (manual or trigger character) will open a new completion session, although we could improve that in the future to reuse the session if no other changes have been made to the document.

The underlying filtering uses sourcekitd's complete.open, complete.update and complete.close requests.

[benlangmuir]

@swift-ci please test