Update to upstream version '2.6.1'
with Debian dir de4cc1005c62c873540e9c8b8067233771377a1f

- add typing annotation to avoid such error in the future

Fixes T3383

Update to upstream version '2.6.0'
with Debian dir a5928cf48b5ed5e74f56196c93fd182d82f7589a

the problem was for datetime<epoch, the timestamp is negative, but since
it's a float that includes the microseconds, if both are true (< epoch
and microsecond > 0), then the computed (int) timestamp was off by one.

Add dedicated tests for this.

Update to upstream version '2.5.1'
with Debian dir 7de8b2d4d70f1a04bd64715de0a11f2f538c8fe1

make sure the snapshot id in OriginVisitStatus refers to existing
Snapshot objects.

Update to upstream version '2.5.0'
with Debian dir 05035d9eb3380a44d4daa228462b7349d05b90b7

If run after py3-full, it overwrites the full coverage info, so most lines
are incorrectly reported as uncovered in Phabricator diffs.

The git_object is what will be actually useful to the vault.

It's also easier to test, because test_identifier.py has the
entire git_object in its test data.

Before this commit, manifests were only computed internally before
hashing, so they were not available to outside modules.

This makes testing the module very painful, because identifier
functions can only be tested by checking the hash; so test failures
did not show mismatches between the computed manifest and
the expected one.

Additionally, the 'git bare cooker' of the vault is likely to use
these as well, as it needs to format git objects in the same format.

Update to upstream version '2.4.2'
with Debian dir 196d5f227c50e9b78022da184ababc6ee414f976

There is a regression that breaks attr.evolve() when updating attributes
that contain an attr class; which we use (eg. for Person or TimestampWithTimezone).

v21.2.0 is expected to fix the issue, but won't be released immediately:
https://github.com/python-attrs/attrs/issues/804#issuecomment-833471190