Improve Apple code signing

[sam-butcher]

Usage and product changes

• We remove the skipIfSigned functionality from the AppleCodeSigner
• We add verbose logging to xcrun calls if it is enabled

Motivation

We've concluded that it is not the responsibility of a maintainer of an open-source library to sign their code for MacOS installers, as such we want to sign these packages ourselves. This may cause us to assume responsibility for issues in our application caused by these packages; this seems reasonable.

We have previously encountered issues when releasing typedb-studio due to a package that was signed, but not specifically for MacOS installers, failing Apple's checks. As such, we want to sign all packages captured by our deepSignJarsRegex - not just unsigned ones. This ensures that all signatures are valid.

However, we still value the deepSignJarsRegex to avoid unnecessarily unpackaging and re-signing every single jar we depend on.

Implementation

We remove the skipIfSigned argument and the functionality gated behind it.

We also fix an issue where the verbose logging flag was not being correctly propagated to our code signing commands.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• This change is trivial and does not require a code or architecture review.

Code

• Packages, classes, and methods have a single domain of responsibility.
• Packages, classes, and methods are grouped into cohesive and consistent domain model.
• The code is canonical and the minimum required to achieve the goal.
• Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• The code is algorithmically efficient and scalable for the whole application.

Architecture

• Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• Any required build and release automations are updated and/or implemented.
• Any new components follows a consistent style with respect to the pre-existing codebase.
• The architecture intuitively reflects the application domain, and is easy to understand.
• The architecture has a well-defined hierarchy of encapsulated components.
• The architecture is extensible and scalable.