WIP: [Tapioca Addon] Support gem RBI generation

[alexcrocha]

WIP

This Draft PR is still a work in progress.

Motivation

To support gem RBI generation, we needed a way to detect changes in Gemfile.lock. Currently, changes to this file cause the Ruby LSP to restart, resulting in loss of access to any previous state information. This limitation prevents monitoring and processing of gem changes.

Implementation

To address this, a snapshot file of Gemfile.lock is created to persist data across server restarts. Upon restart, both the snapshot and the current Gemfile.lock are parsed using Bundler::LockfileParser. If differences are detected, the relevant gem names and specifications are extracted, allowing us to then trigger the gem RBI generation.

This implementation handles gem additions, spec changes, and gem removals.

Tests

[vinistock]

Independent of the code changes themselves, I still have doubts about the UX here. Take this scenario for example:

1. You are working on a branch developing some feature
2. Now, you need to rebase your branch on the latest main
3. The latest main has lockfile changes, but those weren't accompanied by the necessary RBI updates
4. After the rebase, the LSP will immediately generate gem RBIs that are completely unrelated to your work, resulting in untracked changes

I believe we need to try to come up with a strategy to be able to tell if the current developer made the update to the lockfile vs it being updated by something else (like git pull/switching branches/rebasing). Otherwise, it will result in a pretty annoying experience to constantly get unrelated changes.

Maybe, we could remember the launch timestamp of the add-on. When the lockfile is updated, it will trigger a restart and then the add-on can check if the update to the lockfile happened after the previous launch (which should indicate that the current developer made the update). I don't know, there might be better options on how to achieve this.

[alexcrocha]

@vinistock, thanks for pointing this out. I agree that the current behaviour could quickly become frustrating, especially when rebasing and getting unrelated gem RBIs.

I appreciate your suggestion about using the launch timestamp of the add-on to distinguish between lockfile updates made by the developer and those from other actions. I'll experiment with that idea and explore other strategies. Your feedback has given me a lot to think about.

Thanks again for your input!