fix(callbacks)!: SendPacket validation bypass and erroneous event emission are fixed (backport #4568)

[mergify]

This is an automatic backport of pull request #4568 done by Mergify.
Cherry-pick of e192899 has failed:

On branch mergify/bp/release/v7.3.x/pr-4568
Your branch is up to date with 'origin/release/v7.3.x'.

You are currently cherry-picking commit e1928999.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   modules/apps/callbacks/ibc_middleware_test.go
	modified:   modules/apps/callbacks/types/errors.go

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   modules/apps/callbacks/ibc_middleware.go

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

---

Mergify commands and options

More conditions and actions can be found in the documentation.

You can also trigger Mergify actions by commenting on this pull request:

• @Mergifyio refresh will re-evaluate the rules
• @Mergifyio rebase will rebase this PR on its base branch
• @Mergifyio update will merge the base branch into this PR
• @Mergifyio backport <destination> will backport this PR on <destination> branch

Additionally, on Mergify dashboard you can:

• look at your merge queues
• generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.com

[srdtrk]

Pushed empty commit to run the stuck workflows

[colin-axner]

Should we be targetting the callbacks release branch?

[srdtrk]

I think not @colin-axner, this is a breaking change. I think we should create a new release branch from v7.3.x after merging this.

[crodriguezvega]

But if this change requires a callbacks/v0.2.x release branch, shouldn't we first create that release branch from callbacks/v0.1.x and then backport to v0.2.x this change?

[srdtrk]

We could do that @crodriguezvega. But merging this PR to release/v7.3.x and then creating callbacks/v0.2.x from release/v7.3.x ensures that release/v7.3.x has the latest modifications to callbacks which should be the case currently.

So we need to decide whether we want to ensure that release/v7.3.x is up to date on callbacks or not. If not, then we should create the callbacks/v0.2.x branch from callbacks/v0.1.x instead of release/v7.3.x. I don't have a preference.

[crodriguezvega]

ensures that release/v7.3.x has the latest modifications to callbacks which should be the case currently.

Is there a reason or a benefit why release/v7.3.x should be up-to-date with the latest callbacks changes?

[srdtrk]

We have created a new release branch for callbacks and this should be backported there

[damiannolan]

We have created a new release branch for callbacks and this should be backported there

was this ever backported? see #5173

[crodriguezvega]

We have created a new release branch for callbacks and this should be backported there

was this ever backported? see #5173

I don't think so. I can slap the backport label to the PR and let the contributor know that we will close his PR instead.