Fix Channel.__hash__ in multiprocessing contexts

Storing an explicit hash key is fragile in cases that a channel might be
created in a different process to where it might be compared or the hash
used, because the hash seeding can vary depending on how the new
interpreter process was created, especially if it's not done by `fork`.

In this case, transmitting the stored `_hash` over pickle meant that a
`DriveChannel(0)` created in the main process of a macOS runner could
compare equal to a `DriveChannel(0)` created in a separate process
(standard start method `spawn`) and pickled over the wire to the main
process, but have different hashes, violating the Python data model.

Instead, we can just use the standard Python behaviour of creating the
hash on demand when requested; this should typically be preferred unless
absolutely necessary for critical performance reasons, because it will
generally fail safe.

qiskit/pulse/channels.py

@@ -96,7 +96,6 @@ def __init__(self, index: int):
         """
         self._validate_index(index)
         self._index = index
-        self._hash = hash((self.__class__.__name__, self._index))
 
     @property
     def index(self) -> Union[int, ParameterExpression]:
@@ -156,7 +155,7 @@ def __eq__(self, other: "Channel") -> bool:
         return type(self) is type(other) and self._index == other._index
 
     def __hash__(self):
-        return self._hash
+        return hash((type(self), self._index))
 
 
 class PulseChannel(Channel, metaclass=ABCMeta):

releasenotes/notes/fix-pulse-channel-hash-549a8fb5d8738c4d.yaml

@@ -0,0 +1,6 @@
+---
+fixes:
+  - |
+    Fixed the :func:`hash` of Qiskit Pulse ``Channel`` objects (such as :class:`.DriveChannel`) in
+    cases where the channel was transferred from one Python process to another that used a different
+    hash seed.