Use go-native blazer library as a B2 SDK

[mlech-reef]

As https://github.com/Backblaze/blazer is successfully used by the tool like https://github.com/restic/restic since 2017, it looks like it is mature enough to be used as a B2 SDK library in this provider. Using python SDK from go programming language has many drawbacks that using go-native library would solve.

Pros:

1. No need to embed the whole python interpreter, which can significantly increase the boostrap time. Terraform/OpenTofu providers are compiled to executables that the main process executes, sometimes many times in one plan/apply. Each time, the python bindings must be unpacked and executed multiple times as a separate process. This is slow, which we can see in ACC tests that take few minutes with 4 concurrent processes.
2. Possibility to cross-compile every version on just Linux machine, so we can serve more architectures and operating systems without much effort. Go produces fully static binaries, so that provider would work on older versions of macOS and Windows - not like now. On Linux, we use staticx to make the provider statically linked with glibc which causes another problems (e.g. with rpath).
3. Reduced CI time (see point 1)
4. Blazer quality could benefit, as this provider would use most of the functionalities provided by blazer, in opposite to tools like restic.
5. Less error-prone as mapping outputs from the python lib to the golang was causing most of the problems in the past. When keeping everything in golang, we can benefit from having it strongly typed, thus problems detected during the compilation time rather than runtime.

Cons:

1. There are some missing functionalities in blazer that need to be implemented, e.g. notification rules. Also, it would have to be properly maintained and quite up-to-date in order to use new features (and bug fixes) in the future. Not really a cons tbh :)

BR/ Maciej

[metadaddy]

Thanks for this, @mlech-reef. I agree with you. I will discuss with @ppolewicz and @dwubackblaze at our next call.