[ZEPPELIN-6659] Render streaming interpreter output in Angular New UI

[miinhho]

What is this PR for?

The Angular New UI declares PARAGRAPH_APPEND_OUTPUT and PARAGRAPH_UPDATE_OUTPUT in its WebSocket operation enum but does not consume either message. Interpreter output emitted while a paragraph is running
is therefore discarded until the terminal PARAGRAPH snapshot arrives.

This PR adds the missing consumer based on the server's actual wire contract. It declares the receive payloads in the SDK, handles both operations in ParagraphBase, and introduces ParagraphOutputState to fold UPDATE, APPEND, and terminal snapshots into the current paragraph result. APPEND data is accumulated by result index, APPEND received before a typed UPDATE is held until its type is known, and the terminal PARAGRAPH snapshot becomes authoritative so late frames cannot duplicate or overwrite the final result.

The PR also fixes a server-side ordering ambiguity. APPEND events were buffered for up to 100 ms by AppendOutputRunner, while UPDATE events bypassed that queue and could overtake an earlier APPEND. A client
cannot distinguish that delayed APPEND from one genuinely produced after the UPDATE. APPEND and UPDATE now share the same queue, with UPDATE acting as an ordering boundary: preceding APPEND chunks are flushed
before the UPDATE, and subsequent APPEND chunks remain after it.

A focused, versioned capture records the callback-order evidence and observed WebSocket sequences with paragraph streaming enabled and disabled. Reducer tests replay the capture and cover delayed-frame permutations. The client remains defensive against late frames for compatibility with older servers.

The change is limited to the standard paragraph result-rendering path. Application output rendering is unchanged.

What type of PR is it?

Bug Fix

Todos

• Declare the APPEND and UPDATE receive payloads and their type asymmetry
• Consume streaming paragraph output in the Angular New UI
• Preserve APPEND and UPDATE ordering on the server
• Cover coalesced, reordered, and late output events
• Record and replay enabled and disabled streaming captures
• Add browser coverage for output accumulation while RUNNING
• Add the post-fix streaming scenario to the notebook parity registry after [ZEPPELIN-6660] Add notebook parity registry #5456 lands

What is the Jira issue?

• https://issues.apache.org/jira/browse/ZEPPELIN-6659

The reusable WebSocket fixture infrastructure tracked by ZEPPELIN-6665 and ZEPPELIN-6671 is not available yet, so this PR includes the focused capture and ordering replay required by ZEPPELIN-6659.

The notebook parity registry is being introduced by ZEPPELIN-6660 in #5456. After that PR lands, this change will register streaming output as a separate result scenario. The scenario will require the first chunk to be visible while the paragraph is RUNNING, later chunks to accumulate rather than replace earlier output, and the terminal result to contain every chunk exactly once.

How should this be tested?

• Run the server ordering regression test:

./mvnw test -pl zeppelin-server -Dtest=AppendOutputRunnerTest

• Run the frontend reducer and SDK contract tests:

cd zeppelin-web-angular
npm run test:shell -- src/app/core/paragraph-base/paragraph-output-state.spec.ts projects/zeppelin-sdk/src/interfaces/message-data-type-map.interface.spec.ts

• Validate the WebSocket operation contract:

npm run check:websocket-contract

The browser test runs a shell paragraph that prints three chunks separated by 3 and 5 seconds. It verifies that first is visible while the paragraph is RUNNING, second is appended while the paragraph
remains RUNNING, and the FINISHED result contains first, second, and third.

The capture replay additionally verifies coalesced APPEND chunks, APPEND before a typed UPDATE, UPDATE overtaking a queued APPEND, APPEND after the terminal PARAGRAPH, and terminal fallback when zeppelin.websocket.paragraph_status_progress.enable=false.

Questions:

• Does the license files need to update? No.
• Is there breaking changes for older versions? No.
• Does this needs documentation? No.

[voidmatcha]

The overall approach makes sense, but I think two items still need to be addressed before this is ready to merge.

In personalized mode, UPDATE is no longer broadcast, but it still mutates the shared paragraph output buffer. A later checkpoint can therefore persist user-specific output as the shared result. Please skip ownerless incremental updates before mutating the shared buffer, and add a regression test proving that the output is not visible from another user's paragraph after checkpointing. Full owner-aware streaming support can remain tracked in ZEPPELIN-6704.

For reference, the related output-ordering and client-state handling changes are available in this branch:

https://github.com/voidmatcha/zeppelin/tree/fix/pr5460-output-ordering

Separately, PR #5456 for ZEPPELIN-6660 has now been merged. Please rebase this PR onto the latest master and add the streaming-output scenario to the notebook parity registry, as listed in this PR's remaining TODO.