Support signal_with_start

[nagl-stripe]

This PR adds support for signal_with_start_workflow_execution. It has some new tests that go with it:

bundle exec rspec spec/unit/lib/temporal_spec.rb
bundle exec rspec spec/unit/lib/temporal/client_spec.rb
bundle exec rspec spec/unit/lib/temporal/grpc_client_spec.rb
cd examples && bundle exec rspec spec/integration/signal_with_start_spec.rb

And all existing units/integs pass too, except for ./spec/integration/converter_spec.rb, which times out (due to use of a task queue that bin/worker doesn't listen on) before and after this change.

[antstorm]

Great addition, thank you! 🙌 I've suggested a few improvements inline. Can you please also add a spec to spec/unit/lib/temporal/grpc_client_spec.rb?

[antstorm]

nit: Assuming we don't need this dependency

[antstorm]

nit: This needs to be a private method

[antstorm]

This looks a bit weird and definitely needs comments to distinguish different attributes. We should probably consider a few alternatives:

a. Keep the API similar to start_workflow and signal options to kwargs

Temporal.signal_with_start_workflow(
  SignalWithStartWorkflow,
  'signal_name',
  0.1,
  signal_name: 'signal name',
  signal_input: 'expected value'
)

b. Wrap signal attributes into a new object, which can also be assembled within the workflow's on_signal method

Temporal.signal_with_start_workflow(
  SignalWithStartWorkflow,
  Temporal::Signal.new('signal name', 'expected value'),
  'signal_name',
  0.1
)

c. A combination of a & b (preserving start_workflow fingerprint)

Temporal.signal_with_start_workflow(
  SignalWithStartWorkflow,
  'signal_name',
  0.1,
  signal: Temporal::Signal.new('signal name', 'expected value')
)

Open to other suggestions

[antstorm]

Another approach we might consider — instead of exposing another method, we can actually just adopt the start_workflow to accept a with_signal or signal option and then use a different API call based on the presence of that option

[nagl-stripe]

Thanks! I was uncomfortable with this when I wrote it, but found no precedent for named params, decided not to break new stylistic ground, and produced confusion ;)

I went with named params, including one for workflow input because (I think) a single function signature can't have all three of *args, **kwargs, and named params. I can do away with workflow_input in favor of *args, but if the previous statement is correct, it would force signal_name/signal_input out of the signature. signal_name is required, and I don't like the idea of having a required **kwarg.

I didn't overload start_workflow because the java and golang sdks both use a separate method and I wanted to align with that. There's also a subtle difference between the semantics re: whether an existing workflow raises or not.

[nagl-stripe]

Turns out you can have all 3, you just have to specify them in the correct order. Let me know what you think about workflow_input: vs *args. I still prefer it for the explicit juxtaposition with signal_input.

[nagl-stripe]

I'm going to bring this back with different factoring (the optional arguments to start_workflow) in a separate PR.