Replace majority of remaining datatype()s with @dataclass

[Eric-Arellano]

Builds off of #8423.

For native.py, we must use typing.NamedTuple because those call sites can only use basic Python primitives. This is the same as a normal namedtuple, only that it uses a class-based definition with types built-in.

[pierrechevalier83]

Looking good. Couple of comments.

[cosmicexplorer]

Does this apply to all PayloadFields? Does every other PayloadField also have to check if it's frozen? If so, could we at least at TODO here to turn this into a mixin or decorator to avoid error-prone boilerplate?

[Eric-Arellano]

Good question. This is the only PayloadField that used datatype(). The others do a mix of extending tuple, OrderedSet, or implementing their own __hash__().

I'm going to hold off on the TODO because this is a bigger question for what to do with PayloadField. For example, should all of the implementing classes become @dataclasses? Could we rewrite PayloadField to be immutable so that we can stop worrying about this __setattr__() concern? I think a GitHub issue could be appropriate to open!

[cosmicexplorer]

This is why it's sometimes useful to use things like DatatypeMixin, because we might not have had to make any of the changes to this file at all except for moving __new__ to __init__ if we had continued to use the DatatypeMixin interface with .copy() and ._asdict(), which abstracts over the specific way data is represented. Would you be open to it if I submitted a followup (or prework!) PR that demonstrates what I'm talking about?

[Eric-Arellano]

With the below code, we only had to change line 167 from self._asdict() to dataclasses.asdict(self).

All the other changes were simply refactors in realizing that excludes will already be processed through the __init__ so there was no need to explicitly call JarDependency._prepare_excludes.

--

With DatatypeMixin exposing .copy() and ._asdict(), these same behaviors are implemented through dataclass.asdict() and dataclass.replace(). Preferably we will only have one and only one way to implement these two behaviors. DatatypeMixin and those two functions have been useful and were a great utility for the codebase. Now that we have an stdlib version (only possible as of Py3.6), I advocate for going with the solution of leveraging the std lib for better integration with tooling, less code for us to maintain, and lower barrier to entry for new contributors.