Revisit VCL extension point mechanism

[kptdobe]

The extension point mechanism introduced by #86 and enhanced with #92 is really powerful. But it comes with a huge drawback that I did not think about on the first run... each time you add more extension points, you have to update ALL extensions.vcl from ALL customer code using it... Indeed, the file must contain all the subroutines required by helix.vcl, otherwise the VCL is invalid.
This is not future proof and has to be changed (already).
Here is a new proposal:

• extensions.vcl contains only 2 subroutines: hlx_ext_before and hlx_ext_after
• the req.http.X-Ext-State property contains the name of the current subroutine
• each extensible subroutine:
  • set req.http.X-Ext-State with its name
  • call hlx_ext_before
  • ... (does its job)
  • call hlx_ext_after
  • unset req.http.X-Ext-State

Like this extensions.vcl file signature will never change and newly supported extension points will not break existing code.

[kptdobe]

This makes things less readable but upgradable...

[trieloff]

I think we can do better than that. Instead of sending over a full VCL file, we could send over an object with VCL snippets.

Then helix-publish merges the client-provided vcl with a default vclext object and generates the extensions.vcl file from that.

When you add a new extension point in helix.vcl, all you have to do is to add a new, empty property to the default vclext object. Next time someone publishes, the generated extensions.vcl will have one more (empty) subroutine.

[trieloff]

Given that we already post-process helix.vcl for includes, we could even come up with custom syntax like ext(<name>) in the helix.vcl, which would be replaced with call hlx_ext_<name> if the <name> extension exists, and left empty otherwise.

[kptdobe]

This should remain a super advanced and limited feature. Considering the complexity of our VCL (and more to come), the risk that someone breaks the VCL code is so big that I think my approach would just keep it obscur and limited to people doing the effort to understand the VCL code.

[kptdobe]

On the other hand... what you propose is mainly string manipulations... could be a strong approach.

[trieloff]

If you are concerned about abuse, then we can build a whitelist of service configs that are allowed to provide custom VCL in the first place.