AI rewriter supports delta text response events

[petemill]

The Conversation API sends delta updates of text, but the text selection rewriting expects full text on every streaming event call. This PR passes through whether it's a delta update or not (based on the current engine being used). I considered handling this at the API level, but then re-considered since that wouldn't be possible for other action types with more complicated event streams. Even the rewrite event stream response could become more complicated with different event types, and I'm not sure the API client code would have been the best place to decide how to combine delta responses in between events. What do the reviewers think?

Resolves

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[fallaciousreasoning]

In general, I'm okay with this approach. However, I think I'd prefer to handle this at an API level - both of the use cases we have here are going to end up concatenating the bits of the text together, so are probably going to duplicate that logic.

If we do go this way though, could we push the is_delta property into the CompletionEntryEvent struct (maybe a big ask, as its just deserializing a response from the server)? In my ideal world, the data would be something like:

union ConversationEntryData {
    string suggestion;
    string delta;
};

If not, this is fine - it'll unblock the rewriter stuff 😄

[petemill]

In general, I'm okay with this approach. However, I think I'd prefer to handle this at an API level - both of the use cases we have here are going to end up concatenating the bits of the text together, so are probably going to duplicate that logic.

I think what you proposed is a good option - not the low-level API (which would interfere with regular conversation multi-evented responses too), but at the Conversation(Driver) level, which has a specific handler for the selected text / rewriting text generation. In fact, the ConversationDriver already handles text concatenation for the regular conversation entries anyway. I've updated the PR to do that.

If we do go this way though, could we push the is_delta property into the CompletionEntryEvent struct (maybe a big ask, as its just deserializing a response from the server)? In my ideal world, the data would be something like:

I didn't want to go down that route as it has implications for all UI to handle it and these events are stored as conversation history entry data. It's debatable I suppose, but probably best we give consumers simpler events and handle the delta stuff at the Conversation level.

[fallaciousreasoning]

LGTM, thanks for doing this @petemill

[fallaciousreasoning]

👍 I bumped into this when I was playing around with this change 😆