create btcec(/v1) module for legacy consumers

[chappjc]

EDIT: This might need more care to "carve out" a v1 module from an existing multi-module repository to avoid ambiguous import issues for Go 1.16 and older users. https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository

Since the btcd repo updated to a btcec/v2 module, and the btcd main module did not get a major SIV bump, it creates a sticky situation for consumers since there may not be a single compatible revision of btcd to require, depending on their transitive dependencies.

A resolution, at least for consumers of the previous btcec, is to make a btcec-v1 branch, on which the v1 btcec package is made into a module of its own.

What I propose is essentially the following:

https://github.com/btcsuite/btcd/compare/bca4298a...chappjc:btcec/v1?expand=1

With that diff based on the new hypothetical btcec-v1 branch somewhere around bca4298, which is shortly after the last changes to the btcec package prior to the breaking btcec/v2 changes, a btcec/v1.0.0 tag could be created once it is merged.

This module has no dependencies of it's own, so it should be very unproblematic for legacy btcec consumers to switch to it as needed. But these new btcec types would not be compatible with the btcec types needed for other btcd package APIs.

However, I'm not entirely sure what this would do to consumers of pre-btcec/v2 btcd revisions, like the v0.22.0-beta or v0.21.0-beta tag users. Hopefully if you required those revisions it would use the non-module btcec package at those revisions. I think it would only fail to build if you checked out that btcec-v1 branch and tried to build btcd unless the root go.mod was given a require for this new btcec(/v1) module. I think that would be pointless though if the branch is only intended to provide this submodule.

[chappjc]

Just considering how this might play out and if there would be any fallout for btcd module consumers at say v0.22.0-beta, the pkg.go.dev site indicates that the previous package was "v0" and there's now a "v2", so a "v1" would indeed be distinct from the original package that was part of the btcd module.

So I think a v1 should be fairly benign, not breaking any existing btcd consumers, but it's probably worth a note in btcec/v1's README.md that the module is meant to help the transition to the dedicated btcec module without code changes, BUT that its exported types are not compatible with other btcd packages such as txscript that have btcec types in their API. As such, its uses are limited, such as with the go-ethereum use case where only the btcec package is used.

[jacohend]

I currently maintain a project which integrates Tendermint (using old btcec), LND (using btcec/v2), and several client libraries using various btcutil versions. What's been done to btcutil and btcec has created a dependency nightmare for us which will require us forking various libraries to temporarily fix. +1

[chappjc]

If this is done, just need to be extra careful to avoid the even worse nightmare of an ambiguous import (e.g. #1839 (comment), which was eventually resolved in #1851).
So, for btcec, this probably needs a similar resolution with a v0.22.2 tag but with legacy btcec carved out.
My initial guess that a v1 btcec would be "fairly benign" depends on how it's done.