Ignore deprecated proto types for ADT mapping

[denis-egorushkin]

If an ADT mapping has deprecated messages in the proto (i.e. with option deprecated = true), it would be useful to support deriving the reader mapping, even if the respective model types for the deprecated proto types are missing. Currently, it's not possible if any of the model types are missing. Handling the deprecated proto types could be implemented as returning a PbFailure.

The current behavior does not work well for the use case when there is an existing ADT and some of the cases get deprecated. Then the user is forced to replaced the derived mapping with a custom one.

[jan-xyz]

I think there is a misunderstanding of what deprecation means. Deprecation is not removal; Deprecation means it is discouraged to use it (e.g. to signal to users upfront that it will be removed in a next major version). It is still a semantically breaking change to not provide that value or even error out when it is sent. The clean way is to remove the field and bump to the next major version. That being said: I don't think that it is a smart way for teleproto to ignore deprecated fields and messages as that would effectively introduce breaking changes as soon as a field gets deprecated.

[joroKr21]

Yeah I think you're right - better to err on the side of safety than allow automatically generated code to potentially cause production incidents because e.g. a deprecated message was encountered.