validator: allow message deprecation

[silverjam]

Description

@swift-nav/devinfra

See below.

API compatibility

Does this change introduce a API compatibility risk?

No, this message allows existing messages to be renamed with the _DEP or _DEP_A syntax so that they can be deprecated.

JIRA Reference

n/a -- see #1131 (cc @fpezzinosn)

[jungleraptor]

@silverjam I might've given the thumbs up too quickly here.

If a message is deprecated, and another message takes it's place (name), does the new message still have to be backwards compat with the old one?

If not we might need to do more here. The messages are compared based on names, so after the validate_id check, it will still compare the fields of the name against the old name.

Edit: I looked at the PR and it looks like that new message is definitely not compatible with the old one.

We'll probably have to modify this validator script so that it keys the definitions based on their ID's instead of their names.

Gave approval too quickly

[silverjam]

@silverjam I might've given the thumbs up too quickly here.

If a message is deprecated, and another message takes it's place (name), does the new message still have to be backwards compat with the old one?

If not we might need to do more here. The messages are compared based on names, so after the validate_id check, it will still compare the fields of the name against the old name.

Edit: I looked at the PR and it looks like that new message is definitely not compatible with the old one.

New message doesn't need to be backwards compatible, but the old message (with the new name) needs to stay the same, so the same issue applies.

We'll probably have to modify this validator script so that it keys the definitions based on their ID's instead of their names.

I've update the tool to implement this, also applied black, mypy and pylint.

[jungleraptor]

Two things but otherwise looks good:

• I was under the impression that appending fields to messages was legal?
• I thought it might be worthwhile to make the test case for a legal message deprecation change be the change that @fpezzinosn made in his PR. I was going to throw up a PR with that change on a different branch.

[silverjam]

Two things but otherwise looks good:

• I was under the impression that appending fields to messages was legal?

Yeah, I think it might work, but I don't think we've tested it yet, so I was thinking we should make it "illegal" until we can verify that it works and doesn't cause issues. There are certain types of "appending" that shouldn't legal, like having appending something after a variable sized array (but I don't think the generator will allow this either).

• I thought it might be worthwhile to make the test case for a legal message deprecation change be the change that @fpezzinosn made in his PR. I was going to throw up a PR with that change on a different branch.

Ok, sounds good, I'm going to quickly test that this works with @fpezzinosn's branch before merging.

[silverjam]

@isaactorz Any concerns? If not can I get a quick ✅?

[jungleraptor]

LGTM