Add --against-registry flag for buf breaking

[doriable]

This PR adds a --against-registry flag to buf breaking that can be
set in lieu of --against. When --against-registry is set, breaking checks
are run against the latest commit on the default label of the remote module
in the registry.

buf breaking will error if one of --against or --against-registry is
not set:

$ buf breaking
Failure: Must set --against or --against-registry

buf breaking --against-registry will error if not all modules in the input
are named (and thus a remote cannot be resolved):

$ buf breaking --against-registry
Failure: cannot use --against-registry with unnamed module, proto/local

Fixes #3654

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Mar 24, 2025, 7:07 PM

[emcfarlane]

Maybe this could be Module() bufmodule.Module and document that it may be nil? From the docs it seems like the Module.FullName might be empty (like in Module) not that it isn't a Module, as the opaque ID can be empty.

[doriable]

The OpaqueID should always be present:

buf/private/bufpkg/bufmodule/module.go

Lines 42 to 60 in 37b5a2a

	// OpaqueID returns an unstructured ID that can uniquely identify a Module relative
	// to other Modules it was built with from a ModuleSetBuilder.
	//
	// Always present, regardless of whether a Module was provided by a ModuleProvider,
	// or built with a ModuleSetBuilder.
	//
	// An OpaqueID can be used to denote expected uniqueness of content; if two Modules
	// have different IDs, they should be expected to be logically different Modules.
	//
	// An OpaqueID can be used as a human-readable identifier of the Module, suitable for printing
	// to a console. However, the OpaqueID may contain information on local directory structure, so
	// do not log or print it in contexts where such information may be sensitive.
	//
	// An OpaqueID's structure should not be relied upon, and is not a globally-unique identifier.
	// It's uniqueness property only applies to the lifetime of the Module, and only within
	// Modules commonly built from a ModuleSetBuilder.
	//
	// If two Modules have the same FullName, they will have the same OpaqueID.
	OpaqueID() string

My reasoning for not carrying the entire Module around is because the Image should be a compiled version of the Module (and the Module is otherwise lazily loaded) -- so it seems unnecessary... but maybe it's easier?

[doriable]

Discussed outside of the PR: this is mostly for the case of messageRef, where we resolve the message through the bucket without the Module, so there is no FullName or OpaqueID. In those cases, we are not able to use --against-registry flag.

[emcfarlane]

Do you need to check for empty opaque ID here?

[doriable]

Re: the comment above, the OpaqueID should always be present, but I could check for an empty and return a different error under those circumstances (and a syserror).

[doriable]

Adjusted this error for the buffetch.MessageRef case -- given that we don't build the module for those cases, --against-registry basically cannot be used.