* [ci] Migrate to the 1ES template

Context: https://aka.ms/1espt

The build pipeline has been updated to extend the 1ES pipeline template,
which will keep the pipeline up to date with the latest compliance and
security requirements.

Compliance tasks and scans will run automatically as part of artifact
upload steps, which are now referred to as "outputs".  Template outputs
have replaced all instances of the `PublishPipelineArtifact` task.

* Use self template reference

* Test 1es-sign-artifacts yaml branch

* Set compiler/linker flags

* Test removal of xz submodule

* Update flags

* Update flags

* Test template pivot

* Add scan suppressions

* Use main templates branch

* Import more suppressions

* Bump to xz 5.4.6

* Update .gdn

* Use github.com/tukaani-project/xz

* Update suppressions path

* Update conditions and cl/link flags

* Update cl/link flags

* Update flags

* Try a different way to pass args to submodules

* Disable a warning we can't do much about

* Update gdnsuppress:

* Update build_windows, gdnsuppress

* Update gdnsuppress

* Update build images

* Install latest 7.0 sdk for test lanes

* Use latest 7.0 sdk

---------

Co-authored-by: Marek Habersack <[email protected]>

Context: https://eng.ms/docs/cloud-ai-platform/devdiv/one-engineering-system-1es/1es-docs/1es-pipeline-templates/features/sdlanalysis/binskim#limiting-binskim-to-output-directory-in-sdl-binary-analysis

Attempts to speed up artifact publishing steps by telling `binskim` to
only scan the directory that contains the artifacts being uploaded.

Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/25351/APIScan-step-by-step-guide-to-setting-up-a-Pipeline
Context: https://portal.microsofticm.com/imp/v3/incidents/incident/475933338/summary

The `APIScan@2` task has been added to pipeline runs against `main`.
This task should help us identify related issues earlier, rather than
having to wait for a full scan of VS.

I've configured a new [managed identity][0] (MSI) for API Scan, which
allows us to enable a more modern authentication approach when
running API Scan on the `MAUI-1ESPT` agent pool.

A new `$(ApiScanMAUI1ESPTManagedId)` variable has been configured in
the pipeline settings to pass the app ID for this MSI to the
API Scan task.

[0]: https://ms.portal.azure.com/#@microsoft.onmicrosoft.com/resource/subscriptions/cd4829e2-e38b-43d2-8316-2f2009f36f97/resourcegroups/1esobjects/providers/microsoft.managedidentity/userassignedidentities/maui1esptapiscanidentity/overview

Context: https://tukaani.org/xz-backdoor/

In light of the recently discovered backdoor in xz-utils and its
GitHub repository being blocked, remove the submodule from LibZipSharp
and remove all the code to enable lzma compression support in it.

Note that XZ support was disabled by default and was never released
as part of any official LibZipSharp nugets/binaries, therefore we
are not affected in any form or shape by the issue.

The submodule is removed so that it is possible to clone and initialize
this repository.  When the issues surrounding xz-utils are fixed, we can
restore support by reverting this commit.

zlib bumped to v1.3.1 (https://zlib.net/ChangeLog.txt)
zlib-ng bumped v2.1.6 (https://github.com/zlib-ng/zlib-ng/releases/tag/2.1.6)
zstd bumped to v.1.5.6 (https://github.com/facebook/zstd/releases/tag/v1.5.6)

zlib no longer needs to be patched to prevent from building its example programs.

LibZipSharp's own version bumped to 3.2.0

* Update OneLocBuildToken
* Force loc task pool image to windows

… ages! (#142)

* Fix the elusive invalid zip archive issue that has been a problem for ages!

Fixes dotnet/android#8988

We had this odd corrupt zip file issue which kept cropping up on our Azure Pipelines builds.
We had no idea what caused it until now. Some of the data for the local headers of an item (not the central directory) would be written incorrectly. This would result in a zip which may or may not be extractable, it would depend on how resilient the software extracting the data would be.

So, what was happening here was that (sometimes) libzip would start writing some data (most likely the local file header) using our stream source callback, and it would seek a few bytes into the data and then tried to seek back to the beginning. The latter seek was done by giving the seek operation of the callback an offset of 0 which, unfortunately, was also used by the code as a guard as to whether or not to even perform the seek operation. The effect was that we ignored the seek to 0 and the stream remained at whatever the previous seek location was requested, thus corrupting data. It happened only on the very first entry, since that was the only one which would have position 0 within its range.

We discovered that just enabling the strict consistency checks would uncover the issue, so that has been enabled in
a number of unit tests. Once we did that it turns out we were writting the corrupt data ALL the TIME!.
Fixing up the seeking code to take into account that we might want to see to 0 fixed the issue.

* Bump to 3.3.0 due to ABI changes