* Temporary band-aid to force the deletion of dsk.key_dependencies, which
could result in bad dependency information and thereby bad scheduling
when used in `compute_as_if_collection`

* Typo

* Change test to also look for *slightly* overlapping divisions.

* Also raise if the start of an appended partition is equal to the end of
the last partition, as these should be considered overlapping
partitions.

* Remove commented-out code.

* Remove kwarg which is new in pandas 1.4, the default behavior is fine.

Currently codecov pushes an initial failing status on every PR that is
later updated to passing once more CI builds finish. This is annoying.

As far as I can tell from https://docs.codecov.com/docs/merging-reports
this shouldn't be happening, but it is. Here we attempt to stop this
behavior by:

- Only running code coverage on the main test suite that hits most of
  the codebase.
- Setting a minimum number of builds before codecov should push a status
  update.

Hopefully this fixes the problem.

The (experimental) pandas `string[pyarrow]` dtype has some major
performance benefits that we'd like to experiment with in dask. However,
currently `pyarrow.StringArray` objects have a bug in their pickle
implementation where a small slice of the array still serializes the
full (potentially very large) backing buffers (see
https://issues.apache.org/jira/browse/ARROW-10739). Hopefully this is
fixed upstream in pyarrow at some point, but for now we patch around it
by overriding the pickling implementation for `ArrowStringArray` in
pandas. This implementation is efficient, resulting in zero-copy
serialization in most cases.

There is still more work to do to fully support the `string[pyarrow]`
dtype, but I think this PR can go in as is for now.

`prod`/`nanprod` overflow for data at this size. It's not clear why
numpy only raises these warnings _sometimes_, but it makes sense why
they're there. We filter `RuntimeWarning` now for `prod`/`nanprod` (and
only these operations) now to fix this.

CI for these tests has been broken for a while. Since dask no longer has
any HDFS-specific functionality, we're just relying on fsspec here for
hdfs interaction. Since HDFS isn't commonly used, the maintenance burden
here doesn't seem worth it.

* Add codespell pre-commit

* Fix missing newline in setup.cfg

Co-authored-by: Jim Crist-Harif <jcristharif@gmail.com>

[PEP 544](https://www.python.org/dev/peps/pep-0544/) introduces the `Protocol` class to the `typing` module in Python 3.8 (the soon be the minimum supported version, dask/community#213). Writing new Dask collections for [dask-awkward](https://github.com/ContinuumIO/dask-awkward/) has had me thinking about working on a `DaskCollection` protocol. I imagine the benefits to be:

- usage with static type checkers
  - other activity in this area at
    - dask#8295 
    - dask#8706 
    -  dask#8854
  - Python supporting IDEs take advantage of typing
- self-documenting; some improvements to [the custom collections page](https://docs.dask.org/en/latest/custom-collections.html) of the docs. The protocol docs can be autogenerated and added to that page.
- purely opt-in feature

The `typing.runtime_checkable` decorator allows use of `isinstance(x, DaskCollection)` in any code base
that uses Dask collections; for example:

```python
>>> from dask.typing import DaskCollection
>>> import dask.array as da
>>> x = da.zeros((10, 3))
>>> isinstance(x, DaskCollection)
True
```
(though this is an order of magnitude slower than `dask.base.is_dask_collection` which only checks for `x.__dask_graph__() is not None`; static typing checking & built-in interface documentation are the core benefits IMO)

Something else that came up in the brief discussion on a call last week was having `{Scheduler,Worker,Nanny}Plugin` protocols in `distributed`; and perhaps those are better places to start introducing protocols to Dask since on the user side typically more folks would write plugins than new collections.

Currently both Dask and Distributed implement this function with very
slight variations. To attempt to consolidate these, pull in the
Distributed implementation content into the Dask implementation. Then
both Dask & Distributed can use this one function.

…rrectly. (dask#8979)

…9062)

…` and ``aggregate_files`` (dask#9052)

As discussed in dask#9043 (for `chunksize`) and dask#9051 (for `aggregate_files`), I propose that we deprecate two complex and rarely-utilized arguments from `read_parquet`: `chunksize` and `aggregate_files`.

This PR simply adds "pre-deprectation" warnings for the targeted arguments (including links to the relevant Issues discussing their deprecation).  My goal is to find (and inform) whatever users may be depending on these obscure options.

Co-authored-by: Ian Rose <ian.r.rose@gmail.com>

* Use `elif` for `decode` in `ensure_unicode`

* Handle Python Buffer Protocol in `ensure_unicode`

Any other arbitrary object (like `bytearray` or `memoryview` based
objects) can be decoded to `unicode` via `codecs.decode`. This is
analogous to what is done in `ensure_bytes`. So handle this case here.
If this also fails, then raise as usual.

* Include `ensure_unicode` tests for various objects

* Clarify error messages

* Use `uint8` in `array` tests

This is more consistent with the other tests, which also use this type.
Though `int8` also works.

* Pass `bytes` directly to `array`

Appears this already gets interpreted correctly by `array`. Should also
make the code easier to read for other maintainers.

* Use `from array import array`

Avoids the `array.array` bit which is a tad verbose.

Co-authored-by: Peter Andreas Entschev <peter@entschev.com>

Co-authored-by: Peter Andreas Entschev <peter@entschev.com>

Co-authored-by: Peter Andreas Entschev <peter@entschev.com>

As noted by Peter Andreas Entschev <peter@entschev.com>:
Why do we need to compute() results here? assert_eq should take care of
that, plus computing here will potentially lose things attributes such
as meta.

Co-authored-by: Peter Andreas Entschev <peter@entschev.com>

so that we do not break if p is ever a CuPy array for example