fix: avail submission was stuck waiting for finalization

[mtsitrin]

PR Standards

Opening a pull request should be able to meet the following requirements

---

For Author:

• Targeted PR against correct branch
• included the correct type prefix in the PR title
• Linked to Github issue with discussion and accepted design
• Targets only one github issue
• Wrote unit and integration tests
• All CI checks have passed
• Added relevant godoc comments

---

For Reviewer:

• confirmed the correct type prefix in the PR title
• Reviewers assigned
• confirmed all author checklist items have been addressed

---

After reviewer approval:

• In case targets main branch, PR should be squashed and merged.
• In case PR targets a release branch, PR should be rebased.

[codecov]

Codecov Report

Merging #438 (057e0c8) into main (9ce91a0) will decrease coverage by 0.05%.
Report is 1 commits behind head on main.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #438      +/-   ##
==========================================
- Coverage   52.55%   52.50%   -0.05%     
==========================================
  Files          94       94              
  Lines       14404    14421      +17     
==========================================
+ Hits         7570     7572       +2     
- Misses       5760     5774      +14     
- Partials     1074     1075       +1     

Files Changed	Coverage Δ
block/manager.go	69.37% <ø> (-0.06%)	⬇️
da/avail/avail.go	19.14% <0.00%> (-0.70%)	⬇️
da/celestia/celestia.go	62.44% <ø> (ø)
settlement/dymension/dymension.go	69.14% <ø> (-0.95%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[omritoptix]

We only want to panic if the err is from a configuration error (otherwise we keep trying to submit and emit health events).

Seems like you changed the errors returned that they can't be detected as ErrBroacastConfigError so this part will never execute.

[omritoptix]

We only want to panic if the err is from a configuration error (otherwise we keep trying to submit and emit health events) (line 260)

Seems like you changed the errors returned from broadcastTx that they can't be detected as ErrBroacastConfigError so this part will never execute.

[mtsitrin]

I'll revert it back, but few things to notice,

1. the err check is wrong, should be errors.Is instead of ==
2. this error if meant to be unrecoverable, should break the retries loop as well
3. not sure why we panicking for DA errors, but not for SL errors...

[omritoptix]

we're only panicing for configuration/bugs errors not for network errors (i.e base layer unavailable). both for SL and DA.

you can see for example in the SL we're panicing if can't find a key, not passing validation etc.

We don't panic for DA if we failed to send due to network error. same as we don't panic for SL if we failed to send due to network error.