Dask-awkward arrays are not copyable when Coffea has been imported

[jrueb]

Describe the bug
dask-awkward recently fixed a bug, which now enables copying of dask-awkward arrays (dask-contrib/dask-awkward#324). However, when Coffea has been imported, dask-awkward arrays are not copyable at all. I assume this is because of
https://github.com/CoffeaTeam/coffea/blob/558f853d7fcf7313ff8093a48fb1d02bef2a5980/src/coffea/__init__.py#L51C69-L51C69

I consider the ability to copy arrays essential. For example when I apply different JEC uncertainties, I create a copy of my data, adjust the jets in the copies according to the different variations and run my code on each of the copies.

To Reproduce

from copy import copy
import awkward as ak
import dask_awkward as dak
import coffea


a = dak.from_awkward(ak.Array([1]), 1)
a_copy = copy(a)

a_copy will be None, but should be a dask-awkward array (a copy of a).

Coffea version 2023.7.0rc0.

[lgray]

This will be fixed when awkward arrays (and dask awkward arrays) have transient_attrs (a planned feature, scikit-hep/awkward#1391), right now they're not copyable because we need to keep a pointer to the original dask awkward array for various cross reference functionality (and if you recall your earlier issue we cannot simply store a weakref). If we copy/pickle the dask awkward array it mixes descriptions of work and actual work, which results in chaos. The best solution for now is to register a constructor to None in copyreg, which is done on import of coffea.

Unless you have a better solution for not pickling dask-awkward arrays in mind, you shouldn't really need to copy dask awkward arrays in the first place (the concept of doing so is deeply strange in the first place since dask arrays are handles to future work, a copy is the same as multiple references to the same object). I would suggest finding another way to do what you want to do.

[lgray]

Fixed in #949