refactor: include more info in Microsoft stacktrace, when/if available (

#1460)

nit: bodyException() is being populated but never read, which someone…
will *really* not appreciate when they try to make sense of a stacktrace
some day

fix(generic): Make BlobIdToName serialisable (#1459)

Make BlobIdToName serialisable

refactor: (noop; new API) further carve out model-agnostic interface …

…for (#1458)

refactor: TempMediaData techdebt-progress: this cleansup/unblocks
upcoming 'static exporter' I've written that will utilize this exact
same code, but won't be tied to any one DTP model.

fix: Add the missing jackson annotations to SignalRequest (#1452)

refactor: codehealth rename types to reflect axis of transformation (#…

…1451)

this is entirely a change for code clarity, because if you read (before
this patch) the `AnyToAnyImporter#import` generic-params you'll see `To`
being passed in as the source of data (what should be a conceptual
"From").

The cause of that confusion is that there's multiple different
orthogonal transformations happening with/around the
`TransferCompatibilityProvider` and its supporting `AnyToAnyImporter`
class and DTP generally:

1. DTP moves data from a Exporter producing models to an Importer
consuming models
1. we have static functions that convert model A to model B (eg: from
Photos model to a Media model via
[`MediaContainerResource::photoToMedia`][pToMedia])
- this is parallel to the `From` and `To` generic params of
[`java.util.function.Function<From, To>`][Function].
1. `TransferCompatibilityProvider` converts *an importer* (via
`AnyToAnyImporter` and a model-transformer like above) from an importer
of one model type to an importer of another model type.

I'm now using the language of "stand-in importer" to indicate which
importer was selected as the input (think the `g` in `f(g(x)`) to
indicate the key moving piece in that last kind of transformation listed
above.

[Function]:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/function/Function.html
[pToMedia]:
https://github.com/dtinit/data-transfer-project/blob/bca0c7926fb871c7fdd7e206908a87874ec624f2/portability-types-common/src/main/java/org/datatransferproject/types/common/models/media/MediaContainerResource.java#L45

fix(generic): Preserve BLOBS path across copy iterations (#1450)

Changes in diff

1. Using job store to save ID to path mapping 
2. Blobs serializer only parses the tree single depth, it uses job store
to link parent & subfolders across different iterations

fix(generic): don't fail on unknown properties while deserialising Re…

…freshTokenResponse (#1449)

don't fail on unknown properties while deserialising
RefreshTokenResponse

fix: classify microsoft `quotaLimitReached` code as dest. full (#1447)

unfortunately this isn't perfectly correct; `quotaLimitReached` can mean storage quota but _appears_ it also can be used to mean rate-limiting. Unclear, for now.

fix: googphotos http request handling to be self-consistent (#1445)

factors out the common HTTP logic to a middle-tier private func
`makeHttpRequest` to get to a _mostly_ noop cleanup/DRYing of our HTTP
handling. (motivation: some issues we're debugging). Things that prevent
this from being just a true **noop** refactor:

- `makePostRequest` used to only respect its users' request for special
HTTP headers on the _first_ request, but not on subsequent
(token-refresh driven) requests. Now it'll respect it for all requests.
- similar to previous point: _rate limiting_ wasn't consistently
applied, now it's always applied for every write request, and not just
the first.
- similarly, check for HTTP 200 was only done on some request paths, now
it's always done; it's also now a consistent stack trace that will
hopefully be more useful (like the other stack traces we get for bad
responses).
- unlike the above/extant http-200 check (despite not getting an error),
other checks like permission-denied were not always done; now they're
done regardless of getting a response or an error

refactor: clarify Google Photos token-refresh heuristic (#1444)

refactor: clarify Google Photos token-refresh heuristic (similar to recent Microsoft HTTP refactoring).