Handle new execute_intent non-raising behaviour

[andrewn617]

rails/rails#58049 refactored execute_intent to no longer raise errors. Instead execution errors are stored on the query intent and can be checked later by the caller. This is to pave the way for better async execution.

However, semian relies on the raising behaviour to trip the circuit breaker. With this change to Rails, any query that fails mid execution will be considered successful by Semian. And indeed ActiveRecordTrilogyAdapterTest#test_read_timeout_error_opens_the_circuit fails when we bump Rails to this commit.

To solve it, in our execute_intent patch we can check the intent for an error and raise it within the acquire_semian_resource block to trip the circuit breaker. Then we can rescue it and return the result to match the new Rails behaviour.

[Edouard-chin]

It would be good to also rm -rf the Gemfile.lock before the bundle install steps kicks in on CI. This way we are sure bundler picks the latest Rails edge

[andrewn617]

Alright, I took a crack at improving the testing situation for this gem. Now the main gemfile and all the testing gemfiles lock to the latest released version, and I added _edge versions for each. That way we are running all tests against Rails 8.1 and edge.

I had to keep minitest locked to 5.6. If we bump it to 6.0 we get some test failures, so that can be done in a separate PR.

Also, this uncovered we weren't handling PG::ConnectionBad errors that can be raised by 8.1, since edge fixed this behaviour and we were only testing on edge. So I fixed that.

[Edouard-chin]

@adrianna-chang-shopify Usually committing the main Gemfile.lock is enough.

The lockfile in gemfiles/ are mostly CI only, and it's rare that developers need to run BUNDLE_GEMFILE=gemfiles/Rails_8.2 bundle exec rake test. In the event that they have a failing CI for a specific gemfile, then it's better to not have a lockfile committed so that tests run with the same dependencies as on CI (the latest one).

Committing the Gemfile.lock remove all possible friction to contribute to a project

[adrianna-chang-shopify]

The lockfile in gemfiles/ are mostly CI only

@Edouard-chin , yep fair, in this case though, should we remove all lockfiles under gemfiles/? As long as the main lockfile is committed to help contributors, it would be advantageous for the CI-only ones to resolve their latest permitted dependencies right?

We can probably also drop the rm from CI then if we're not tracking the edge lockfiles with git.

[Edouard-chin]

in this case though, should we remove all lockfiles under gemfiles/

@adrianna-chang-shopify Ah yes, great point. I think we should