fix(compiler)!: webhook payload containing message with special characters causes failure

[NickHackman]

Use the implementation made upstream in drone/envsubst#27 to fix escape sequence handling to prevent yaml parsing to fail due to invalid escape sequences.

Issue: go-vela/community#702

[NickHackman]

This is an indirect dependency

❯ go mod why github.com/drone/envsubst
# github.com/drone/envsubst
github.com/go-vela/server/api
github.com/go-vela/types/pipeline
github.com/drone/envsubst

Going to update this dependency in types/pipeline as well

[NickHackman]

PR to update types/pipeline go-vela/types#284

[codecov]

Codecov Report

Merging #793 (4f2edf2) into main (3fd6215) will not change coverage.
The diff coverage is n/a.

❗ Current head 4f2edf2 differs from pull request most recent head 8e4ed33. Consider uploading reports for the commit 8e4ed33 to get more accurate results

@@           Coverage Diff           @@
##             main     #793   +/-   ##
=======================================
  Coverage   57.73%   57.73%           
=======================================
  Files         263      263           
  Lines       15911    15911           
=======================================
  Hits         9187     9187           
  Misses       6310     6310           
  Partials      414      414           

Impacted Files	Coverage Δ
compiler/native/substitute.go	70.00% <ø> (ø)

[NickHackman]

"full-review" failed due to other lint checks done by golangci-lint

[jbrockopp]

LGTM

[plyr4]

looks great, thanks @NickHackman :D
one hesitation is that it changes the escape functionality in the critical path for most of the executor container code.
one example: https://github.com/go-vela/worker/blob/main/executor/linux/step.go#L59-L71
some users might have put workarounds in place for having bogus escape sequences in secrets.

im excited for the fix, so i'd say admins should be watchful on rolling this change out, and also should mark this as a breaking change in the PR and in the release notes.
either way, love it!

[NickHackman]

@plyr4 good call out, this would impact users who have tried to hack around the issue in the first place. Hopefully that's a very small subset of users who need remediation here

with further testing theres a bit more to the issue at large

[ecrupper]

@NickHackman Hi Nick! Thanks for the PR. I pulled down both the changes in this PR as well as your changes in the types PR. I had a few buggy payloads to test, and it does indeed look like the escape character error is resolved, however some new YAML parser error arose, such as mapping values not allowed in this context. While I do think we should probably update this library, I'm wondering if there's more to this issue + perhaps another way to solve? Perhaps some sanitization on our end? I will update the issue with a payload I tested that got another parser error. Curious what others think in terms of whether we merge this in as a "step in the right direction" or if we prefer a catch-all sanitization solution?

[NickHackman]

@ecrupper Awesome, fire away with examples here. I assume any issue we face is coming from the upstream library. I'll do my best to patch things if we can get cases that fail.

Ideally these issues are all fixed in the upstream library. Vela shouldn't need to patch it, but whatever is seen as best

[ecrupper]

Will update the original issue with anything else we find related to compiler errors from weird character sequences. For now, we know this fixes a few things and doesn't break anything from what we can tell. Merging! Thanks again @NickHackman !