feat: conditionally panic-recover

[dwisiswant0]

Proposed changes

As discussed with @Mzack9999, we should avoid overusing panic-recover. We need to review the RCA first to determine whether this is an exceptional situation or if it's a higher-level function meant to recover from a panic. This approach will help us establish a robust error-handling strategy.

The implementation of panic-recover should be conditional and NOT applied when running in a CI environment AND IS temporary. Once we've caught all errors and made the necessary corrections, we can remove the deferred recover function.

Things to note:

• Go version upgraded.

Unresolved questions:

• Does this have any impact on our internal services (for instance, PDCP) or tools that integrate with Nuclei?

Checklist

• Pull request is created against the dev branch
• All checks passed (lint, unit/integration/regression tests etc.) with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

[Mzack9999]

lgtm - Panics in GitHub actions should be visible and be investigated

[tarunKoyalwar]

implementation lgtm!

Context on existing panic recovery

earlier we removed all recover mechanism that were related to nuclei code , the existing ones currently are to catch third party library ( in this case goja related panics) , but as suggested i think we can safely throw them when running in CI

We kept 3rd party lib panic recovery, because we observed some panics especially in go-rod in very rare cases which didn't directly affect any application logic and wasn't reproducable

---

Not sure about RCA but if this is a follow-up of #5547 (review) , Go StdLib provides customization when running race detector , we can set halt_on_error and exit_code in GORACE env variable in github build action job/workflow and it will halt and thus job will fail

ref: https://go.dev/doc/articles/race_detector

cc: @Mzack9999

[tarunKoyalwar]

also build is failing locally for library code , i think this is due to recent change in template signature pr

[dwisiswant0]

[...] we can set halt_on_error and exit_code in GORACE env variable in github build action job/workflow and it will halt and thus job will fail

Note that a data race is UB and by default, it cannot be recovered - alias runtime does not raise a panic. So even without adjusting the GORACE, it'll still remain halted though.

The motive is to analyze and later determine whether this recovery is for an "exceptional situation or if it's a higher-level function", and we're making sure to dodge any kind of so-called shadow errors - which, potentially, trigger another panic and the root cause would be from that. So, this is all about correctness.

also build is failing locally for library code , i think this is due to recent change in template signature pr

Rebased. Please try again.