Remove binary codec sv2

[Shourya742]

closes: #1462

[plebhash]

#1860 is about to deprecate the ping-pong examples

I guess we already found a workaround for any CI-blocking issues here, but just to point out that if they cause problems again, we don't need to spend too much time trying to find clever solutions

[plebhash]

we shouldn't be slipping commits titled something something to PRs

bc96abf

[plebhash]

we'll need to bump MAJOR

$ cargo +stable semver-checks
    Building binary_sv2 v4.0.0 (current)
       Built [   2.407s] (current)
     Parsing binary_sv2 v4.0.0 (current)
      Parsed [   0.006s] (current)
    Building binary_sv2 v4.0.0 (baseline)
       Built [   2.129s] (baseline)
     Parsing binary_sv2 v4.0.0 (baseline)
      Parsed [   0.002s] (baseline)
    Checking binary_sv2 v4.0.0 -> v4.0.0 (no change)
     Checked [   0.003s] 95 checks: 94 pass, 1 fail, 0 warn, 0 skip

--- failure function_missing: pub fn removed or renamed ---

Description:
A publicly-visible function cannot be imported by its prior path. A `pub use` may have been removed, or the function itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.37.0/src/lints/function_missing.ron

Failed in:
  function binary_sv2::clone_message, previously in file /Users/plebhash/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/binary_sv2-4.0.0/src/lib.rs:25

     Summary semver requires new major version: 1 major and 0 minor checks failed

[Shourya742]

we shouldn't be slipping commits titled something something to PRs

bc96abf

That slipped, I wanted to rebase it to other commit in the history.

[Shourya742]

@plebhash whats your opinion on the rigidity?

[GitGab19]

Shouldn't we bump PATCH here?

cc @plebhash

[Shourya742]

Patch would be required as we updated its dependency, good point.

[Shourya742]

As API's are not changing, so we don't need to update major and minor versions.

[plebhash]

hmm idk

from the perspective of someone who's using channels_sv2, does it really matter where the internal implementation details are coming from?

are we changing the behavior of anything, or just moving things around?

maybe I have some blindspot, but my first instinct here would not to bump anything

[GitGab19]

If we don't bump PATCH here we won't update crates published to crates.io during release.

So we would keep having the old binary_sv2 on those published crates.

[Shourya742]

I will bump the patch for them, in the same PR.

[plebhash]

@GitGab19 @Shourya742 we should be careful in extrapolating this into an umbrella rule where we always bump PATCH just because some dependencies were updated

handlers_sv2 is now at v0.2.1 on this repo, while the published version is still at v0.1.0... so v0.2.0 will never be published

it doesn't make sense to bump PATCH for something that hasn't been published yet

[plebhash]

channels_sv2 is also at v2.0.1, while the last published version is at v1.0.2, so v2.0.0 will never be published

[plebhash]

codec_sv2 is also at v4.0.1 while the last published version is at v3.0.1, so v4.0.0 will never be published

[Shourya742]

Shoot, I didn't looked at the crates.io versions for them. Thanks for pointing it out.

[GitGab19]

I would squash a891dcc, since it's reverting something you did on this PR.

Please reword commit 25f3417 which doesn't make sense (there's no stratum-common) and it's not descriptive at all.

Usually, I tend to always squash fmt and clippy commits with the related changes, to not pollute git history too much.

[Shourya742]

I would squash a891dcc, since it's reverting something you did on this PR.

Please reword commit 25f3417 which doesn't make sense (there's no stratum-common) and it's not descriptive at all.

Usually, I tend to always squash fmt and clippy commits with the related changes, to not pollute git history too much.

I am yet to restruct the history, let me do it.

[Shourya742]

I would squash a891dcc, since it's reverting something you did on this PR.

Please reword commit 25f3417 which doesn't make sense (there's no stratum-common) and it's not descriptive at all.

Usually, I tend to always squash fmt and clippy commits with the related changes, to not pollute git history too much.

Should be ok now.