feat!: port mutexbot actions to rust and add isolation channels

[jcgruenhage]

Problem

To send notifcations for dev and prod deployments into different channels we needed to use the isolation channel feature of mutexbot.

Summary of changes

• Port to rust, to make dynamic inclusion of channel isolation parameters easier. It would've been possible to do this in bash, but I'm confident that the static checks done by rust will help making this less error prone in the long run.
• Support isolation_channel parameters for reserving/releasing
• Merge mutexbot/reserve and mutexbot/release into one mutexbot action to dedupe code
• Parameters change from kebap-case to snake_case, because of rust best practices. I was not able to make rust happy with kebap-case in parameters. If should be possible to do that by patching https://github.com/42ByteLabs/ghactions

Testing

I have created a test workflow in a temporary repo under https://github.com/neondatabase-labs/tmp-mutexbot-test/blob/main/.github/workflows/test.yml, which successfully reserves the resources. A workflow run that shows this working is https://github.com/neondatabase-labs/tmp-mutexbot-test/actions/runs/12694965092/job/35385895290

[bayandin]

Personally, I think Rust is a bit too much for this task: we have less Rust experience in the company than in Python, for example. Also it's (relatively) harder to install and configure locally.
But, if you think that Rust is the best tool for this task, let's keep it.

The thing that we need to fix — it shouldn't take 5 minutes to setup the action

[jcgruenhage]

if you think that Rust is the best tool for this task, let's keep it.

I'm not sure about "best tool for the task", but it's the one I'm most accustomed to. We could probably achieve the same in python, even with static checks using mypy to ensure type safety and other static analysis tools, but getting this going in Rust was the quicker route for me personally, as I'm more used to that ecosystem than to python and the static analysis tools there.

The thing that we need to fix — it shouldn't take 5 minutes to setup the action

It will not:

• I've cut down the dependencies, which reduced build times to ~2 minutes instead of ~5
• If I'm not mistaken, a runner that sees this action for a second time will already have the image cached, so as soon as this runs on our own runners instead of shared github runners, it will be instant most of the times. I need to verify this assumption before rolling this out.
• There's always the alternative of pre-building the images instead of having gha build them on demand, which is what I'll do if this my previous assumption turns out to be false

[jcgruenhage]

There's a pre-built image now that's coming from CI here. We're down to 6 seconds from job start to successful reservation.