Sanitize migrations and parse comment to disable specific statement validation

[danicc097]

What does this PR do?

• (rather critical) Ensure migration files don't get actually executed by removing begin, commit and rollback.

• As a workaround for Parameter values in INSERT #61 (and any other bug that arises), add an option to disable statements validation in the same way as the complete file
  
  I believe the warning should be explicit as it is now since ideally this flag should not be used in any case and let the extension do its work

What issues does this PR fix or reference?

Is it tested? How?

[yas7010uv]

@danicc097

Thank you for your suggestion.

In my opinion, there is no need for a warning against disabling the language server because it is explicitly specified by the user.

Currently, the whole file disable feature also don't output a warning.
And, there are cases where users are using disable feature because they do not want to output warnings.

[danicc097]

It's a fair point in the case of global disabling, etc. since it is always in the first document line. However, for statements that disabling line could be in the middle of a long file with lots of statements. In that case, I think it's helpful to open the file and instantly see there are warnings and where they are in the sidebar:

however it's also true that some people will not want that.

What about a diagnosticLevel flag? error, warning, information, hint which are the existing ones. This could be interesting not just for this case. Defaults to error.

[yas7010uv]

Interesting idea!

However, it is confusing to the user that the disable feature is treated as different levels for the entire file and for the separated statements.

I would like to add the disableFlagDiagnoticsLevel option ( ignore, warning, statementsWarning, default ignore ).

If you are using plpgsql_check, you are not preferred to ignore static analysis warnings because of the desable flag.

[yas7010uv]

Recently, the settings have become more complicated, contrary to my preference.

I understand that many users have different requirements,
but I would like this tool to be used with fewer settings if possible.

[danicc097]

Perhaps it's a good idea to make statement settings independent, same as with plpgsqlLanguageServer.migrations, so these things won't pollute the rest of the configuration.

Imagine I add plpgsqlLanguageServer.statements.diagnosticsLevel : "warning", and then you decide to add a global plpgsqlLanguageServer.disableFlagDiagnoticsLevel. This way things would be independent.
You wouldn't need to specify disableFlagDiagnoticsLevel's statementsWarning, statements... to account for the optional statements analysis feature, because we could treat plpgsqlLanguageServer.statements.diagnosticsLevel with higher specificity. And this applies to any new configuration option to be added in the future.

This has the drawback of messier logic in the code in some situations (like figure out what diagnostics to show) but settings would be kept simple for the user if no optional features are used

[yas7010uv]

I agree statements options.

And I propose this setting schema.
Because many additional diagnostics levels are expected (And can set global and statements independently).

{
    "plpgsqlLanguageServer.diagnosticsLevels": {
        "disableFlag": "ignore"
    },
    "plpgsqlLanguageServer.statements": {
        "diagnosticsLevels": {
            "disableFlag": "warning"
        }
    },
}

What do you think?

[danicc097]

Yes, completely agree with that.