[Grouped Updates] The VendorUpdater class watermarks DependencyFile objects it creates

[brrygrdn]

Groundwork to fix #7319

Grouped Updates need to manage the aggregation of DependencyFile objects return from updaters in two ways:

• They need the maintain an overall list of every file that changed during each step to create the PR
• The need to maintain a list of the manifest files to pass into subsequent updaters so the changes are performed iteratively

In the case of vendor files, we need them to be present in the overall file list for (1), but we do not want them to be passed into subsequent updaters as their interface does not expect to have to filter them out and retrofitting this filtering across all our ecosystems isn't the most practical approach.

The Changes

This PR does the following

• Adds a vendored_file attribute to Dependabot::DependencyFile which is false by default
• Splits out a base class from the VendorUpdater class to provide support for managing arbitrary files within an Updater that don't fall within the remit of the FileUpdater itself, i.e. they are not a manifest file, nor are they a vendor file
• Use this new base class to manage .pnp.* and install state files for yarn berry within our NPM library
• Updater the concrete VendorUpdater to set vendored_file: true on any DependecyFile objects it creates

Rationale

This change introduces the vendor_file watermarking without changing any behaviour or modifying the Group Update processes to use it to isolate and de-risk this from the larger effort to handle grouped updates + vendoring.

[brrygrdn]

👋🏻 @pavera I just wanted to check that my changes around the npm file updater made sense for the yarn files being managed

[brrygrdn]

I considered an alternative approach of adding a new argument to VendorUpdater rather than creating a 'generic' ArtifactUpdater, something like

def initialise(repo_contents_path:, vendor_dir:, create_vendored_files: true)

Although this would work had result in less churn to the API, I felt this didn't make the intent that vendor files need some special handling clear enough and it would extremely easy for a subtle bug if we were to develop a new use for this utility class similar to the calls in the NPM FileUpdater.

The split of 'utility class to grab any artefact outside the manifest files' and 'specific class to manage vendored dependencies' seemed like a safer, more intentional interface.

[bdragon]

Thanks for explaining your thought process. Seems well-reasoned to me and straightforward inheritance like this seems preferable to weaving in switching logic 👍

[brrygrdn]

This was an opportunistic change to allow us to optimise very slightly to avoid reading any files we don't plan on using I've made in passing.

I'm ok with backing this out as it is scope creep, but it was a fairly quick thing to add on.

[bdragon]

Thanks for the callout 👍 I don't see any issue with it, especially given its size/impact.

[bdragon]

Looks great!

[bdragon]

This is a private method in the base class, so it feels a little sneaky for this subclass to know it should override it, but then again this is ruby so nbd.

[bdragon]

Thanks for the callout 👍 I don't see any issue with it, especially given its size/impact.

[bdragon]

Thanks for explaining your thought process. Seems well-reasoned to me and straightforward inheritance like this seems preferable to weaving in switching logic 👍