The configuration can be extended by adding additional counter participants to existing
synchronizers. If a given synchronizer is not already configured then it will be ignored
without error.

The configuration can be extended by adding additional counter participants to existing
synchronizers. If a given synchronizer is not already configured then it will be ignored
without error.

Lists for the given synchronizers the configuration of metrics for slow
counter-participants (i.e., that are behind in sending commitments).

If `synchronizers` is empty, the command lists config for all synchronizers:
- The participants in the distinguished group, which have two metrics:
  the maximum number of intervals that a participant is behind, and the number of
  participants that are behind by at least `thresholdDistinguished` reconciliation
  intervals
- The participants not in the distinguished group, which have two metrics:
  the maximum number of intervals that a participant is behind, and the number of
  participants that are behind by at least `thresholdDefault` reconciliation intervals
- Parameters `thresholdDistinguished` and `thresholdDefault`
- The participants in `individualMetrics`, which have individual metrics per participant
  showing how many reconciliation intervals that participant is behind

Lists for every participant and synchronizer the number of intervals that the participant
is behind in sending commitments if that participant is behind by at least threshold
intervals.

If `counterParticipants` is empty, the command considers all counter-participants.
If `synchronizers` is empty, the command considers all synchronizers.
If `threshold` is not set, the command considers 0.

For counter-participant that never sent a commitment, the output shows they are
behind by MaxInt.

Retrieves the latest (i.e., w.r.t. the query execution time) configuration of waiting for
commitments from counter-participants.

The configuration for waiting for commitments from counter-participants is returned as
two sets: a set of ignored counter-participants, the synchronizers and the timestamp,
and a set of not-ignored counter-participants and the synchronizers.

Filters by the specified counter-participants and synchronizers. If the
counter-participant and / or synchronizers are empty, it considers all synchronizers and
participants known to the participant, regardless of whether they share contracts with
the participant.

Even if some participants may not be connected to some synchronizers at the time the
query executes, the response still includes them if they are known to the participant or
specified in the arguments.

Returns the contract states (created, assigned, unassigned, archived, unknown) of the
given contracts on all synchronizers the participant knows from the beginning of time
until the present time on each synchronizer.

The command returns best-effort the contract changes available. Specifically, it does not
fail if the ACS and/or reassignment state has been pruned during the time interval, or
if parts of the time interval are ahead of the clean ACS state.

Optionally returns the contract payload if requested and available.

Parameters:
- contracts: The contract ids whose state and payload we want to fetch.
- timestamp: The timestamp when some counter-participants reported the given contracts
  as active on the expected synchronizer.
- expectedSynchronizerId: The synchronizer that the contracts are expected to be
  active on.
- downloadPayload: If true, the payload of the contracts is also downloaded.
- timeout: Time limit for the grpc call to complete.

Optional filtering through the parameters:
- synchronizerTimeRanges: Lists commitments received on the given synchronizers whose
  period overlaps with any of the given time ranges per synchronizer.
  If the list is empty, considers all synchronizers the participant is connected to.
  For synchronizers with an empty time range, considers the latest period the participant
  knows of for that synchronizer. Synchronizers can appear multiple times in the list
  with various time ranges, in which case we consider the union of the time ranges.
- counterParticipants: Lists commitments received only from the given
  counter-participants. If a counter-participant is not a counter-participant on some
  synchronizer, no commitments appear in the reply from that counter-participant on that
  synchronizer.
- commitmentState: Lists commitments that are in one of the given states.
  By default considers all states:
  - MATCH: the remote commitment matches the local commitment
  - MISMATCH: the remote commitment does not match the local commitment
  - BUFFERED: the remote commitment is buffered because the corresponding local
    commitment has not been computed yet
  - OUTSTANDING: we expect a remote commitment that has not yet been received
- verboseMode: If false, the reply does not contain the commitment bytes.
  If true, the reply contains:
  - In case of a mismatch, the reply contains both the received and the locally computed
    commitment that do not match.
  - In case of outstanding, the reply does not contain any commitment.
  - In all other cases (match and buffered), the reply contains the received commitment.

Specifically, the command returns a map from synchronizer IDs to tuples of sent
commitment data, specifying the period, target counter-participant, the commitment state,
and additional data according to verbose mode.

Optional filtering through the parameters:
- synchronizerTimeRanges: Lists commitments received on the given synchronizers whose
  period overlap with any of the given time ranges per synchronizer.
  If the list is empty, considers all synchronizers the participant is connected to.
  For synchronizers with an empty time range, considers the latest period the participant
  knows of for that synchronizer.
  Synchronizers can appear multiple times in the list with various time ranges, in which
  case we consider the union of the time ranges.
- counterParticipants: Lists commitments sent only to the given counter-participants.
  If a counter-participant is not a counter-participant on some synchronizer, no
  commitments appear in the reply for that counter-participant on that synchronizer.
- commitmentState: Lists sent commitments that are in one of the given states.
  By default considers all states:
  - MATCH: The local commitment matches the remote commitment
  - MISMATCH: The local commitment does not match the remote commitment
  - NOT_COMPARED: The local commitment has been computed and sent but no corresponding
    remote commitment has been received, which essentially indicates that a
    counter-participant is running behind.
- verboseMode: If true, the reply contains the commitment bytes, as follows:
  - In case of a mismatch, the reply contains both the received and the locally computed
    commitment that do not match.
  - In all other cases (MATCH and NOT_COMPARED), the reply contains the sent commitment
    bytes.

Retrieves the contract ids and the reassignment counters of the shared active contracts
at the given timestamp and on the given synchronizer. Returns an error if the participant
cannot retrieve the data for the given commitment anymore.

Parameters:
- commitment: The commitment to be opened.
- physicalSynchronizerId: The synchronizer for which the commitment was computed.
- timestamp: The timestamp of the commitment. Needs to correspond to a commitment tick.
- counterParticipant: The counter participant to whom we previously sent the commitment.
- outputFile: Optional file to which the result is written.
- timeout: Time limit for the grpc call to complete.

Parameters:
- synchronizerAlias: The alias of the synchronizer
- start: Lowest time exclusive
- end: Highest time inclusive
- counterParticipant: Optionally filter by counter participant

The command is useful if the participant's commitments got corrupted due to a bug. It
reinitializes the commitments for the given synchronizers and counter-participants, and
containing contracts with stakeholders including the given parties.

If `synchronizers` is empty, the command considers all synchronizers.
If `counterParticipants` is empty, the command considers all counter-participants.
If `partyIds` is empty, the command considers all stakeholder groups.

`timeout` specifies how long the commands waits for the reinitialization to complete.
Granularities smaller than a second are ignored. Past this timeout, the operator can
query the status of the reinitialization using `commitment_reinitialization_status`.

The command returns a sequence pairs of synchronizer IDs and the reinitialization status
for each synchronizer: either the ACS timestamp of the reinitialization, or an error
message if reinitialization failed.

The configurations can be removed from distinguished counter participant and
synchronizers use empty sequences correlates to selecting all, so removing all
distinguished participants from a synchronizer can be done with Seq.empty for
`counterParticipantsDistinguished` and Seq(SynchronizerId) for synchronizers.
Leaving both sequences empty clears all configs on all synchronizers.

The configurations can be removed from individual metrics counter participant and
synchronizers use empty sequences correlates to selecting all, so removing all individual
metrics participants from a synchronizer can be done with Seq.empty for
`individualMetrics` and Seq(SynchronizerId) for synchronizers. Leaving both sequences
empty clears all configs on all synchronizers.

Configure metrics for slow counter-participants (i.e., that are behind in sending
commitments) and configure thresholds for when a counter-participant is deemed
slow.

The configurations are per synchronizer or set of synchronizers and concern the
following metrics issued per synchronizer:
- The maximum number of intervals that a distinguished participant falls behind.
  All participants that are not in the distinguished or the individual group are
  automatically part of the default group.
- The maximum number of intervals that a participant in the default groups falls
  behind.
- The number of participants in the distinguished group that are behind by at least
  `thresholdDistinguished` reconciliation intervals.
- The number of participants not in the distinguished or the individual group that are
  behind by at least `thresholdDefault` reconciliation intervals.
- Separate metric for each participant in `individualMetrics` argument tracking how many
  intervals that participant is behind.

Disabling waiting for commitments disregards these counter-participants w.r.t. pruning,
which gives up non-repudiation for those counter-participants, but increases pruning
resilience to failures and slowdowns of those counter-participants and/or the network.
If the participant set is empty, the command does nothing.

Enables waiting for commitments, which blocks pruning at offsets where commitments from
these counter-participants are missing.

Waiting for commitments from all counter-participants is the default behavior;
explicitly enabling waiting for commitments is only necessary if it was previously
disabled.

If the participant set is empty or the synchronizer set is empty, the command does
nothing.

List DARs installed on this participant
Parameters:
- filterName: filter by name
- filterDescription: filter by description
- limit: Limit number of results (default none)

Can be used to remove a DAR from the participant, if the following conditions are
satisfied:
1. The main package of the DAR must be unused -- there should be no active contract from
   this package

2. All package dependencies of the DAR should either be unused or contained in another of
   the participant node's uploaded DARs. Canton uses this restriction to ensure that the
   package dependencies of the DAR don't become "stranded" if they're in use.

3. The main package of the dar should not be vetted. If it is vetted, Canton will try to
   automatically revoke the vetting for the main package of the DAR, but this automatic
   vetting revocation will only succeed if the main package vetting originates from a
   standard `dars.upload`. Even if the automatic revocation fails, you can always
   manually revoke the package vetting.

If synchronizeVetting is true (default), then the command will block until the
participant has observed the vetting transactions to be registered with the synchronizer.

Daml code is normally shipped as a Dar archive and must explicitly be uploaded to a
participant. A Dar is a collection of LF-packages, the native binary representation of
Daml smart contracts.

The Dar can be provided either as a link to a local file or as a URL. If a URL is
provided, then any request headers can be provided as a map. The Dar will be
downloaded and then uploaded to the participant.

In order to use Daml templates on a participant, the Dar must first be uploaded and then
vetted by the participant. Vetting will ensure that other participants can check
whether they can actually send a transaction referring to a particular Daml package and
participant.
Packages must be vetted on each synchronizer by registering a VettedPackages topology
transaction.

If synchronizerId is not set (default), the packages will be vetted, if the participant
is connected to only one synchronizer.
If synchronizeVetting is true (default), then the command will block until the
participant has observed the vetting transactions to be registered with the synchronizer.

This command waits for the vetting transaction to be successfully registered on the
synchronizer.
This is the safe default setting minimizing race conditions.

Note that synchronize vetting might block on permissioned synchronizers that do not just
allow participants to update the topology state. In such cases, synchronizeVetting should
be turned off.

Synchronize vetting can be invoked manually using
$participant.package.synchronize_vettings()

Daml code is normally shipped as a Dar archive and must explicitly be uploaded to a
participant. A Dar is a collection of LF-packages, the native binary representation of
Daml smart contracts.

The Dars can be provided either as a link to a local file or as a URL. If a URL is
provided, then any request headers can be provided as a map. The Dars will be
downloaded and then uploaded to the participant.

In order to use Daml templates on a participant, the Dars must first be uploaded and then
vetted by the participant. Vetting will ensure that other participants can check whether
they can actually send a transaction referring to a particular Daml package and
participant.
Packages must be vetted on each synchronizer by registering a VettedPackages topology
transaction.

If synchronizerId is not set (default), the packages will be vetted, if the participant
is connected to only one synchronizer.
If synchronizeVetting is true (default), then the command will block until the
participant has observed the vetting transactions to be registered with the synchronizer.

This command waits for the vetting transaction to be successfully registered on the
synchronizer. This is the safe default setting minimizing race conditions.

Note that synchronize vetting might block on permissioned synchronizers that do not just
allow participants to update the topology state. In such cases, synchronizeVetting should
be turned off.

Synchronize vetting can be invoked manually using
$participant.package.synchronize_vettings()

Performs the same DAR and Daml package validation checks that the upload call performs,
but with no effects on the target participants: the DAR is not persisted or vetted.

This command succeeds if the vetting command used to vet the DAR's packages
was symmetric and resulted in a single vetting topology transaction for all the packages
in the DAR.

This command is potentially dangerous and misuse can lead the participant to fail in
processing transactions.

When instances reside on different nodes, their database migration can be run in parallel
to save time. Please not that the migration commands must however must be run on each
node individually, because remote migration through `participants.remote...` is not
supported.

In some rare cases, we change already applied database migration files in a new release
and the repair command resets the checksums we use to ensure that in general already
applied migration files have not been changed.

You should only use `db.repair_migration` when advised and otherwise use it at your own
risk - in the worst case running it may lead to data corruption when an incompatible
database migration (one that should be rejected because the already applied database
migration files have changed) is subsequently falsely applied.

Yields false, if the synchronizer is not connected or not healthy.
Yields false, if the synchronizer is configured in the Canton configuration and
the participant is not active from the perspective of the synchronizer.
Uses the local clock to evaluate `ParticipantSynchronizerPermission.login_after`.

The connect macro performs a series of commands in order to connect this participant to
a synchronizer.

First, `register` will be invoked with the given arguments, but first registered
with `manualConnect = true`. If you already set `manualConnect = true`, then nothing else
will happen and you will have to do the remaining steps yourselves.

Finally, the command will invoke `reconnect` to startup the connection.

If the reconnect succeeded, the registered configuration will be updated
with `manualStart = true`. If anything fails, the synchronizer will remain registered
with `manualConnect = true` and you will have to perform these steps manually.

Parameters:
- synchronizerAlias: The name you will be using to refer to this synchronizer. Cannot be
  changed anymore.
- connection: The connection string to connect to this synchronizer.
  I.e. https://url:port
- manualConnect: Whether this connection should be handled manually and also excluded
  from automatic re-connect.
- physicalSynchronizerId: Optionally the physical id you expect to see on this
  synchronizer.
- certificatesPath: Path to TLS certificate files to use as a trust anchor.
- priority: The priority of the synchronizer. The higher the more likely a synchronizer
  will be used.
- timeTrackerConfig: The configuration for the synchronizer time tracker.
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default All)

This variant of connect expects an instance with a sequencer connection.

Otherwise the behaviour is equivalent to the connect command with explicit arguments.
If the synchronizer is already configured, the synchronizer connection will be attempted.
If however the synchronizer is offline, the command will fail.

Generally, this macro should only be used for the first connection to a new synchronizer.
However, for convenience, we support idempotent invocations where subsequent calls just
ensure that the participant reconnects to the synchronizer.

Parameters:
- synchronizerAlias: The name you will be using to refer to this synchronizer. Cannot be
  changed anymore.
- connections: The list of sequencer connections, can be defined by urls.
- manualConnect: Whether this connection should be handled manually and also excluded
  from automatic re-connect.
- physicalSynchronizerId: An optional Synchronizer Id to ensure the connection is made
  to the correct synchronizer.
- priority: The priority of the synchronizer. The higher the more likely a synchronizer
  will be used.
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.
- sequencerTrustThreshold: Set the minimum number of sequencers that must agree before
  a message is considered valid.
- sequencerLivenessMargin: Set the number of extra subscriptions to maintain beyond
  `sequencerTrustThreshold` in order to ensure liveness.
- submissionRequestAmplification: Define how often client should try to send a submission
  request that is eligible for deduplication.
- sequencerConnectionPoolDelays: Define the various delays used by the sequencer
  connection pool.
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default All)

This variant of connect expects a synchronizer connection config.

Otherwise the behaviour is equivalent to the connect command with explicit arguments.
If the synchronizer is already configured, the synchronizer connection will be attempted.
If however the synchronizer is offline, the command will fail.

Generally, this macro should only be used for the first connection to a new synchronizer.
However, for convenience, we support idempotent invocations where subsequent calls just
ensure that the participant reconnects to the synchronizer.

Parameters:
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default all)

Parameters:
- sequencer: A local sequencer reference
- alias: The name you will be using to refer to this synchronizer. Can not be changed
  anymore.
- manualConnect: Whether this connection should be handled manually and also excluded
  from automatic re-connect.
- physicalSynchronizerId: An optional Synchronizer Id to ensure the connection is made to
  the correct synchronizer.
- maxRetryDelayMillis: Maximal amount of time (in milliseconds) between two connection
  attempts.
- priority: The priority of the synchronizer. The higher the more likely a synchronizer
  will be used.
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default All)

Parameters:
- synchronizerAlias: The name you will be using to refer to this synchronizer.
  Cannot be changed anymore.
- sequencers: The list of sequencer references to connect to.
- manualConnect: Whether this connection should be handled manually and also excluded
  from automatic re-connect.
- physicalSynchronizerId: An optional Synchronizer Id to ensure the connection is made
  to the correct synchronizer.
- priority: The priority of the synchronizer. The higher the more likely a synchronizer
  will be used.
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.
- sequencerTrustThreshold: Set the minimum number of sequencers that must agree before
  a message is considered valid.
- sequencerLivenessMargin: Set the number of extra subscriptions to maintain beyond
  `sequencerTrustThreshold` in order to ensure liveness.
- submissionRequestAmplification: Define how often client should try to send a submission
  request that is eligible for deduplication.
- sequencerConnectionPoolDelays: Define the various delays used by the sequencer
  connection pool.
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default All)

Synchronizers can provide many endpoints to connect to for availability and performance
benefits.
This version of connect allows specifying multiple endpoints for a single synchronizer
connection:
- connect_multi("mysynchronizer", Seq(sequencer1, sequencer2))
  or:
- connect_multi("mysynchronizer", Seq("https://host1.mysynchronizer.net",
    "https://host2.mysynchronizer.net", "https://host3.mysynchronizer.net"))

To create a more advanced connection config use synchronizers.to_config with a single
host, then use config.addConnection to add additional connections before connecting:
config = myparticipaint.synchronizers.to_config("mysynchronizer",
  "https://host1.mysynchronizer.net", ...otherArguments)
config = config.addConnection("https://host2.mysynchronizer.net",
  "https://host3.mysynchronizer.net")
myparticipant.synchronizers.connect(config)

Parameters:
- synchronizerAlias: The name you will be using to refer to this synchronizer.
  Cannot be changed anymore.
- connections: The sequencer connection definitions (can be an URL) to connect to this
  synchronizer. I.e. https://url:port
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default All)

Fails if there is no active connection for the alias,
or the active connection does not have a known synchronizer id.

For each returned synchronizer, the boolean indicates whether the participant is
currently connected to the synchronizer.

On all the sequencers from the specified synchronizer, all existing authentication
tokens for this participant will be revoked.

Note that the participant is not disconnected from the synchronizer; only the connections
to the sequencers are closed. The participant will automatically reopen connections,
perform a challenge-response and obtain new tokens.

Parameters:
- synchronizerAlias: the synchronizer alias from which to logout

If a logical synchronizer upgrade has been announced, the config for the successor
synchronizer gets updated automatically on the basis of the provided config for the
active synchronizer.
Parameters:
- synchronizerAlias: Alias of the synchronizer
- modifier: The change to be applied to the config.
- validation: The validations which need to be done to the connection.
- physicalSynchronizerId: Physical id of the synchronizer. If empty, the currently
  active connection will be updated (if none is active, an error is returned).
  If not empty, the active synchronizer must match the provided physical synchronizer id.

Perform a local manual logical synchronizer upgrade to switch to the designated successor

Unlike the other method above, a new config is specified and replaces the current one.
This should be used only if the goal is to change the synchronizer connection config
as part of the upgrade (e.g., if one sequencer does not migrate).


Parameters:
- currentPsid: current physical synchronizer id
- successorPsid: physical synchronizer id of the successor
- upgradeTime:
     If defined:
       - MUST be higher than any message received by the node on the synchronizer id
       - Upgrade will not start until all events until upgrade_time have been processed
     If empty:
       - Clean synchronizer index from ledger api server will be used.
- config: Config for the the new synchronizer

Perform a local manual logical synchronizer upgrade to
switch to the designated successor.

Parameters:
- currentPsid: current physical synchronizer id
- successorPsid: physical synchronizer id of the successor
- upgradeTime:
     If defined:
       - MUST be higher than any message received by the node on the synchronizer id
       - Upgrade will not start until all events until upgrade_time have been processed
     If empty:
       - Clean synchronizer index from ledger api server will be used.
- sequencerSuccessors:
     The sequencer connection definitions to connect to the new sequencers.
     SHOULD contain one entry for each sequencer currently registered by the participant

Fails if there is no active connection for the alias,
or the active connection does not have a known physical synchronizer id.

Idempotent attempts to re-establish a connection to a certain synchronizer.
If retry is set to false, the command will throw an exception if unsuccessful.
If retry is set to true, the command will terminate after the first attempt with the
result, but the server will keep on retrying to connect to the synchronizer.

Parameters:
- synchronizerAlias: The name you will be using to refer to this synchronizer. Cannot be
  changed anymore.
- retry: Whether the reconnect should keep on retrying until it succeeded or abort
  noisily if the connection attempt fails.
- synchronize: A timeout duration indicating how long to wait for all topology changes to
  have been effected on all local nodes.

Parameters:
- ignoreFailures: If set to true (default), we'll attempt to connect to all,
  ignoring any failure
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.

Idempotent attempts to re-establish a connection to the given local synchronizer.
Same behaviour as generic reconnect.

Parameters:
- synchronizerAlias: The synchronizer alias to connect to
- retry: Whether the reconnect should keep on retrying until it succeeded or abort
  noisily if the connection attempt fails.
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.

Idempotent attempts to re-establish a connection to the given local synchronizer.
Same behaviour as generic reconnect.

Parameters:
- ref: The synchronizer reference to connect to
- retry: Whether the reconnect should keep on retrying until it succeeded or abort
  noisily if the connection attempt fails.
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.

Parameters:
- sequencer: A local sequencer reference
- alias: The name you will be using to refer to this synchronizer. Cannot be changed
  anymore.
- performHandshake: If true (default), will perform a handshake with the synchronizer.
  If no, will only store the configuration without any query to the synchronizer.
- manualConnect: Whether this connection should be handled manually and also excluded
  from automatic re-connect.
- physicalSynchronizerId: An optional Synchronizer Id to ensure the connection is made
  to the correct synchronizer.
- maxRetryDelayMillis: Maximal amount of time (in milliseconds) between two connection
  attempts.
- priority: The priority of the synchronizer. The higher the more likely a synchronizer
  will be used.
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default All)

Parameters:
- config: Config for the synchronizer connection
- performHandshake: If true (default), will perform handshake with the synchronizer.
  If no, will only store configuration without any query to the synchronizer.
- validation: Whether to validate the connectivity and ids of the given sequencers
  (default All)
- synchronize: A timeout duration indicating how long to wait for all topology changes
  to have been effected on all local nodes.

This command finds the current number of pending command submissions and transactions on
a selected synchronizer.

There is no synchronization between pending command submissions and transactions. And the
respective counts are an indication only!

This command is in particular useful to re-assure oneself that there are currently no
in-flight submissions or transactions present for the selected synchronizer. Such
re-assurance is then helpful to proceed with repair operations, for example.

The command fails if there is no active connection for the alias,
or the active connection does not have a known physical synchronizer id.

Generates a comprehensive health report for the local Canton process and any connected
remote nodes.

Parameters:
- outputFile: Specifies the file path to save the report. If not set, a default path is
  used.
- timeout: Sets a custom timeout for gathering data, useful for large reports from slow
  remote nodes.
- chunkSize: Adjusts the data stream chunk size from remote nodes. Use this to prevent
  gRPC errors related to 'max inbound message size'

Yields Some(duration) in case of success and None in case of failure.

Yields the duration in case of success and throws a RuntimeException in case of failure.

If the default logback configuration is used, this will change the log level of the
process.

Returns all public keys that have been added to the key registry.

Optional arguments can be used for filtering.

This command is a convenience wrapper for `list_key_owners`, taking an explicit keyOwner
as search argument. The response includes the public keys.

This command allows deep inspection of the topology state. The response includes the
public keys.

Optional filterKeyOwnerType type can be `ParticipantId.Code`, `MediatorId.Code`,
`SequencerId.Code`.

Import a public key and store it together with a name used to provide some
context to that key.

Load a public key from a file and store it together with a name used to provide some
context to that key.

Parameters:
- name: The optional name argument allows you to store an associated string for your
  convenience.
- keySpec: The keySpec can be used to select a key specification, e.g., which elliptic
  curve to use, and the default spec is used if left unspecified.

Parameters:
- name: The optional name argument allows you to store an associated string for your
  convenience.
- usage: The usage specifies the intended use for the signing key that can be:
  - Namespace: for the root namespace key that defines a node's identity and signs
    topology requests.
  - SequencerAuthentication: for a signing key that authenticates members of the network
    towards a sequencer;
  - Protocol: for a signing key that deals with all the signing that happens as part of
    the protocol.
- keySpec: The keySpec can be used to select a key specification, e.g., which elliptic
  curve to use, and the default spec is used if left unspecified.

Returns all public keys to the corresponding private keys in the key vault.

Optional arguments can be used for filtering.

Parameters:
- kmsKeyId: The id for the KMS encryption key.
- name: The optional name argument allows you to store an associated string for your
  convenience.

Parameters:
- kmsKeyId: The id for the KMS signing key.
- usage: The usage specifies the intended use for the signing key that can be:
  - Namespace: for the root namespace key that defines a node's identity and signs
    topology requests.
  - SequencerAuthentication: for a signing key that authenticates members of the
    network towards a sequencer.
  - Protocol: for a signing key that deals with all the signing that happens as part of
    the protocol.
- name: The optional name argument allows you to store an associated string for your
  convenience.

Rotates an existing encryption or signing key stored externally in a KMS with a
pre-generated key.

NOTE: A namespace root signing key CANNOT be rotated by this command.

Parameters:
- fingerprint: The fingerprint of the key we want to rotate.
- newKmsKeyId: The id of the new KMS key (e.g. Resource Name).
- name: An optional name for the new key.

Rotates an existing encryption or signing key.

NOTE: A namespace root or intermediate signing key CANNOT be rotated by this command.

Parameters:
- fingerprint: The fingerprint of the key we want to rotate.
- name: An optional name for the new key.

For a participant node it rotates the signing and encryption key pair.

For a sequencer or mediator node it rotates the signing key pair as those nodes do not
have an encryption key pair.

NOTE: Namespace root or intermediate signing keys are NOT rotated by this command.

Change the wrapper key (e.g. AWS KMS key) being used to encrypt the private keys in the
store.

Parameters:
- newWrapperKeyId: The optional new wrapper key id to be used. If the wrapper key id is
  empty Canton will generate a new key based on the current configuration.

Upload the previously downloaded key pair.

Parameters:
- pairBytes: The binary representation of a previously downloaded key pair.
- name: The (optional) descriptive name of the key pair.
- password: Optional password to decrypt an encrypted key pair.

Upload the previously downloaded key pair from a file.

Parameters:
- filename: The name of the file holding the key pair.
- name: The (optional) descriptive name of the key pair.
- password: Optional password to decrypt an encrypted key pair.

Return the highest participant ledger offset whose record time is before or at the given
one (if any) at which pruning is safely possible

Return the largest participant ledger offset that has been processed before or at the
specified timestamp.

The time is measured on the participant's local clock at some point while the
participant has processed the the event.

Returns `None` if no such offset exists.

The schedule consists of a "cron" expression and "max_duration" and "retention" durations
as described in the `get_schedule` command description. Additionally "prune_internally"
indicates if the schedule mandates pruning of internal state.

The schedule consists of a "cron" expression and "max_duration" and "retention"
durations. The cron string indicates the points in time at which pruning should begin in
the GMT time zone, and the maximum duration indicates how long from the start time
pruning is allowed to run as long as pruning has not finished pruning up to the specified
retention period.

Returns `None` if no schedule has been configured via `set_schedule` or if
`clear_schedule` has been invoked.

Prunes the participant ledger up to the specified offset inclusively returning `Unit`
if the ledger has been successfully pruned.

Note that upon successful pruning, subsequent attempts to read transactions via
`ledger_api.transactions.flat` or `ledger_api.transactions.trees` or command completions
via ``ledger_api.completions.list`` by specifying a begin offset lower than the returned
pruning offset will result in a ``NOT_FOUND`` error.

The ``prune`` operation performs a "full prune" freeing up significantly more space and
also performs additional safety checks returning a ``NOT_FOUND`` error if ``pruneUpTo``
is higher than the offset returned by ``find_safe_offset`` on any synchronizer with
events preceding the pruning offset.