Use namespace from schedule activity worker

[dnr]

What changed?
In the scheduler workflow activities, instead of checking that namespace + namespace id match, just use the namespace + id that's known to the activity worker.

Why?
This reduces the chance of security bugs resulting from forgetting checks.

How did you test it?
CI

Potential risks
Changing activity inputs does not break determinism, so the workflow should be compatible (verified with a local test).

Is hotfix candidate?

[yiminc]

Most of the activities are used as local activities (except the WatchWorkflow which could be used by regular activity), we probably should not register them as regular activity (thus remove the possibility from been invoked by user code.)

[dnr]

Most of the activities are used as local activities (except the WatchWorkflow which could be used by regular activity), we probably should not register them as regular activity (thus remove the possibility from been invoked by user code.)

Good idea. But I don't see how to do it:

If I don't register them at all, then running local activities doesn't work (because they're not registered with the actual struct instance and I can't get it from the workflow). If I register them like this:

worker.RegisterActivityWithOptions(activities.StartWorkflow, activity.RegisterOptions{Name: ""})

then it looks like it registers them with an external name anyway (based on this code: https://github.com/temporalio/sdk-go/blob/dbb8e5471b98e090a41bcd64b1261d66e5fefe23/internal/internal_worker.go#L556-L574)

Is there a trick I'm missing?

[yiminc]

Local activity does not require registration. You can access local activity from within workflow as:

	var a *activities
	var result string
	err := workflow.ExecuteLocalActivity(ctx, a.LocalActivity, name).Get(ctx, &result)

[dnr]

Local activity does not require registration. You can access local activity from within workflow as:

	var a *activities
	var result string
	err := workflow.ExecuteLocalActivity(ctx, a.LocalActivity, name).Get(ctx, &result)

But then the receiver (a) is nil inside the local activity. I need that to get clients and stuff. I guess there's BackgroundActivityContext but the comments say it's not recommended anymore.

[yiminc]

This PR is good to go. We can work on activity to local activity in separate PR.