Upgrade to trillium-client 0.4.6

[divergentdave]

This should fix an issue we ran into with reverse proxies. I'm currently working on re-running that integration test.

[divergentdave]

FWIW I tried re-running Dependabot last week to bump this, and it failed with the following message. Not sure what's going on in this case.

updater | 2023/11/23 02:13:23 INFO <job_753419045> Requirements to unlock update_not_possible
updater | 2023/11/23 02:13:23 INFO <job_753419045> Requirements update strategy bump_versions
updater | 2023/11/23 02:13:23 INFO <job_753419045> No update possible for trillium-client 0.4.5

[jbr]

Is trillium-http pinned for some reason? I'm less familiar with how dependabot resolves that sort of thing than cargo update

[divergentdave]

I tested this against Caddy and it has resolved the issue.

I tried running cargo update trillium-client locally, and it did nothing. Note that this command is part of Cargo, and its help text says it will "Update dependencies as recorded in the local lock file". I then tried running cargo upgrade -p trillium-client, which comes from the cargo-edit package. This edited the three Cargo.toml files, but then failed during the step "Upgrading recursive dependencies":

error: failed to select a version for wasm-bindgen.
... required by package wasm-bindgen-futures v0.4.38
... which satisfies dependency wasm-bindgen-futures = "^0.4.10" (locked to 0.4.38) of package async-std v1.12.0
... which satisfies dependency async-std = "^1" (locked to 1.12.0) of package migration v0.1.0 (/home/david/Code/ppm/divviup-api/migration)
versions that meet the requirements ^0.2.88 are: 0.2.89

all possible versions conflict with previously selected packages.

previously selected package wasm-bindgen v0.2.87
... which satisfies dependency wasm-bindgen = "^0.2.87" of package hpke-dispatch v0.5.1
... which satisfies dependency hpke-dispatch = "^0.5.1" (locked to 0.5.1) of package divviup-cli v0.1.0 (/home/david/Code/ppm/divviup-api/cli)

failed to select a version for wasm-bindgen which could resolve this conflict
Error: recursive dependency update failed

Subsequently running cargo check --workspace --locked seems fine. I haven't looked closely at Dependabot's update logic, but I suspect it's running in an issue similar to that with cargo-upgrade. Dependabot does invoke Cargo somehow, based on the HTTP proxy logs. There must be some issue that's preventing it from re-resolving transitive dependencies compared to the latest Cargo CLI tool.

[jbr]

[email protected] is hot off the cargo presses, we might as well jump right to that