Handle max signal count limit for signal transfer task

[yycptt]

What changed?

• Handle max signal count limit for signal transfer task
• API change: Add failed cause for signal count limit api#265

Why?

• Limit total signal count per workflow

How did you test it?

• Added unit test. Tested locally.

Potential risks

Is hotfix candidate?

• Yes.

[yiminc]

shall we define a specific error type for this? (it is ok to use internal error type)

[yycptt]

yeah I think that makes sense. Theoretically, that api can return invalid argument error for other reasons like blob size limit exceeded. Right now should be fine though, because the fact that we never handle that error type means other cases never happen and it must be signal count limit.

I will create a task for adding the new error type, I think it's also useful for other per workflow limit we plan to enforce in the future. For this patch, I think checking invalid argument should be ok.

internal error type

I don't quite follow. Do you mean history service returns the newly defined internal error type, and frontend convert it back to invalid argument before returning to customer? Otherwise I don't see how internal error type can work.