Missing pickle support for Sentinel #720
Description
Support for pickle is expressed as a motivation in PEP 661, but currently typing_extensions.Sentinel implements an explicit rejection of pickle support.
The reason for the rejection was that the suggested pickle implementation could change in the future, but the solution to that would've been to use pickles singleton support which would've deferred any specific pickle implementation to any hypothetical future object including swapping out the typing_extensions sentinel with a future builtin sentinel. It was understandable to worry about this since I've seen many others get it wrong, but singletons are inherently forward compatible.
Pickling as a singleton was suggested right away by TeamSpen210 in #594, but was ignored possibly due to being too contrived to understand possibly due to singletons themselves not being a well documented part of pickle.
I've made PR's to fix this but I may have given the impression that I'm just making them for fun, but I actually need pickle support. I strongly want to move away from sentinel libraries which have a poor reduce implementation which locks pickled data to that library.
Obviously the default for pickling instances is bad and was rightly rejected, and many of the typical options to reduce an instance are also rightly rejected, but singletons simply reference an objects fully qualified __module__.__name__ and do not care what that object is later replaced with.
The solution to support singletons is to either assign self.__module__ and return the sentinels qualified name as lone string from __reduce__ like in PR #617, or to treat new sentinels as types rather than instances and rely on the singleton support inherit in pickling types like in PR #715.