Move non-public proto IDL errors to internal api

[vytautas-karpavicius]

What changed?
Moved non-public error messages to internal part of proto IDLs.

Why?
Those messages are not communicated out of frontend service. Validated with:

$ cat idls/thrift/cadence.thrift | grep -E "shared.+Error" | awk '{print $2}' | sort -u
shared.BadRequestError
shared.CancellationAlreadyRequestedError
shared.ClientVersionNotSupportedError
shared.DomainAlreadyExistsError
shared.DomainNotActiveError
shared.EntityNotExistsError
shared.InternalServiceError
shared.LimitExceededError
shared.QueryFailedError
shared.ServiceBusyError
shared.WorkflowExecutionAlreadyStartedError

Only those errors are returned by the front-end. Other messages are used when communicating between Cadence server components. Therefore lets move them to internal part of API and do not expose.

This PR also updates:

• RetryTaskV2Error to wrap start/end event id/version with VersionHistoryItem so that they would get optional semantics. (Either both id/version is set or none of them).
• Added owner fields to ShardOwnershipLostError. It was forgotten during initial IDLs creation.

[coveralls]

Coverage increased (+0.02%) to 64.602% when pulling dfe2799 on vytautas-karpavicius:proto-non-public-errors into dfde9ba on uber:master.

[Groxx]

LGTM. Reducing public is always good 👍

I don't suppose there are any "X could be moved to Y, it's only used there" linters for proto? Proactive maintenance like this is sorta troublesome to rely on, though I'm always in favor of doing it.

[Groxx]

seems unused, as it's not part of the generated code

[vytautas-karpavicius]

This is actually required for VersionHistoryItem which is in this file.

[vytautas-karpavicius]

LGTM. Reducing public is always good 👍

I don't suppose there are any "X could be moved to Y, it's only used there" linters for proto? Proactive maintenance like this is sorta troublesome to rely on, though I'm always in favor of doing it.

I have checked buf rules. There doesn't seems anything like that.

Though in this particular case, it would not help. As error messages are not really attached to rpc methods (unlike thrift). So there would be no way to track them down. For this case I actually used existing thrift IDLs to pull out this information.