Add support for update admitted event

[Quinn-With-Two-Ns]

Add support for update admitted event. Required some modification to how the Java SDK batches event during replay because when the SDK processed an update admitted event while replaying it needs to know if it was accepted or not. Preciously the SDK batches events like [WFT started, WFT completed, Command events] and now it batches events like [Non command events, WFT scheduled, WFT started, WFT completed, Command events]
.

[Sushisource]

Makes sense

[Sushisource]

GH won't let me suggest here because it's a whiny baby about deleted lines, but looks like this could be:

    List<HistoryEvent> res;
    if (readyToFetch.size() == 1) {
      HistoryEvent event = readyToFetch.get(0);
      res = Collections.singletonList(event));
    } else {
      res = new ArrayList<>(readyToFetch);
    }
    Optional<HistoryEvent> wftStarted = workflowTaskCompletedEvent;
    workflowTaskCompletedEvent = Optional.empty();
    readyToFetch.clear();
    return new EventBatch(wftStarted, res);

[Sushisource]

Nice 👍 glad we're consistent now

[Quinn-With-Two-Ns]

Yeah I just took the comment straight from core

[Sushisource]

Hehe I noticed :)

[dandavison]

I'm happy to see the definitions converge. This comment helped me a lot when I implemented this in core. I think the comment should probably be moved up to l.134 where the instance attribute is defined

  /**
   * Is workflow executing new code or replaying from the history. Note that this flag ALWAYS flips
   * to true for the time when we apply events from the server even if the commands were created by
   * an actual execution with replaying=false.
   */
  private boolean replaying;

[Quinn-With-Two-Ns]

@Sushisource @dandavison This is something we should test in Core as well, previously due to server limitations, it wasn't possible to have an [update, signal, update] in history, but with update admitted it now is. We should check the handlers get called in the correct order.

[dandavison]

Nice, I really like the new consistency between core and Java regarding isReplaying.

Not specific to Java but one thing that's at the back of mind and worries me slightly is: I've made server code not send protocol messages for durably admitted updates. But it's a fragile contract. What would happen if a server engineer accidentally changed that? Do we have tests that would fail in a fairly understandable way?

[dandavison]

I'm happy to see the definitions converge. This comment helped me a lot when I implemented this in core. I think the comment should probably be moved up to l.134 where the instance attribute is defined

  /**
   * Is workflow executing new code or replaying from the history. Note that this flag ALWAYS flips
   * to true for the time when we apply events from the server even if the commands were created by
   * an actual execution with replaying=false.
   */
  private boolean replaying;