Completion: fix bad trailing } completion

[vovakulikov]

Fixes bad completion case https://github.com/sourcegraph/cody/discussions/358#discussioncomment-6531096

After hours of catching corner cases, I think we can't rely on regexp-based shouldIncludeClosingLine logic here. Counting brackets doesn't provide much value when we don't know about the structure of the expression where we try to insert completions. This PR just tries to handle the simple case with an empty completion line with a closed bracket symbol and cut off this completion.

@philipp-spiess I don't think I fully understand how this is possible, but unit tests tell me that completion should be cut off, but vscode manual test shows that this problem is still there. Let me know if you have a minute for a quick pair on this.

Test plan

• Try to force } completion (see original GitHub discussion thread for the example)
• Check that there is no } compleation

[philipp-spiess]

The shouldIncludeClosingLine is only relevant for the multi-line completion truncation, where we find out if we should include one line below the current indentation. I would not base the solution to this problem in that code (because when we later use tree sitter to parse the response, we'd want it to emit everything for the current function scope and that would also include the closing tags) and we then do a follow-up step to try and merge it into the existing code (which is what the suffix matching tries to do now).

So instead, I'd see if we can fix this in the suffix matching logic only. WDYT?

My initial idea here is that this should 100% be a case of "the completion matches the next line". The only way it doesn't is because the completion can not delete code and we always append the same line prefix whitespace (even though Claude doesn't know about).

My two ideas are:

• We handle the case of potential "dedent" from Claude specifically for the next line logic. That would mean that if you compare the first line of the completion with the suffix, we do not match on the exact indentation anymore.
• We try to be smart and make more sense of Claude's response. I think we can't really rely on the whitespace that's why I’m not sure this works but if the completion that Claude sends us + the prompt we send it does not have the same indentation as our current prefix, we should maybe discard the completion? This would also fix https://github.com/sourcegraph/cody/discussions/358#discussioncomment-6519515 where Claude is not emitting a \n in the completion but the current suffix already has a \n and we just trim it for the Claude prompt.

[vovakulikov]

As we discussed with @philipp-spiess, this PR doesn't try to do anything about bracket counting and parsing and just aims to catch some narrow cases with single close bracket completion.

[philipp-spiess]

LGTM! Just one comment inline :)