Handle deprecated blocks or attributes on hcl.syntax level

[malud]

Note: enhancement from code perspective which will solve a current bug.

In general we need a component which acts as syntax pre-processor to rename deprecated block, attribute or error_handler names/types. Additionally we can log such a rename once with a warning and a hint for the upcoming version which will drop the support for the old names. For example our beta_ features.

A current situation for the beta_permissions should be fixed since Couper does not understand the old _beta__ permission prefix. See #673 .

Should be executed after our config-merge pre-processor.

Rough data format: [type][key]struct{new: val, version: upcoming} and key (e.g. beta_permission) should refer to the old one for easy lookups. Type could be block,attribute or error_handler.

[alex-schneider]

Should be executed after our config-merge pre-processor.

We must deprecate before merge process, because we call validate() for each parsed body.

[johakoch]

What about the renamed beta_granted_permissions and beta_required_permission request context variables?

[johakoch]

What about the renamed beta_granted_permissions and beta_required_permission request context variables?

I guess that it's not so easy to find references to request.context.beta_granted_permissions or request.context.beta_required_permission, rename them and log a warning.

However, in eval/context.go

func newVariable(ctx context.Context, cookies []*http.Cookie, headers http.Header) ContextMap {
...
    gp, _ := ctx.Value(request.GrantedPermissions).([]string)
    if len(gp) > 0 {
        ctxAcMap[grantedPermissions] = seetie.GoToValue(gp)
    }
    if rp, permissionSet := ctx.Value(request.RequiredPermission).(string); permissionSet {
        ctxAcMap[requiredPermission] = seetie.GoToValue(rp)
    }

we could additionally store the values under beta_-prefixed keys.

There will only be values if permission-related attributes are configured. And if these are beta_-prefixed, there will be log warnings.

[johakoch]

https://github.com/avenga/couper-vscode/pull/126 added a message containing the version with which a feature was deprecated. Now that, in Couper, we have a version, with which a deprecated feature is no longer supported, should we add this to the VSCode message, too?

[johakoch]

avenga/couper-vscode#126 added a message containing the version with which a feature was deprecated. Now that, in Couper, we have a version, with which a deprecated feature is no longer supported, should we add this to the VSCode message, too?

https://github.com/avenga/couper-vscode/pull/129