Fix console encoding issues

[ramondeklein]

Originally posted by @ramondeklein in #3057 (comment)

The console uses manual URL parameter encoding using the custom encodeURLString and decodeURLString functions. It's not needed to encode the parameters using a custom function, because Javascript already provides the encodeURIComponent(...) and decodeURIComponent functions to encode/decode text when it's used in an URL. The advantage is that the Go server automatically decodes the parameters without needing to call any functions. Another advantage is that URLs look better (especially if they don't have any encoded characters).

It's a bit strange that the Swagger code generator doesn't perform this encoding, because it's the only sane thing to do. I'm not the only one who's wondering why that's not the default. Fortunately, it can be fixed with a hook that will automatically add this:

module.exports = {
    hooks: {
        onInsertPathParam: (paramName) => `encodeURIComponent(${paramName})`,
    }
};

That way, we don't need to bother which parameters need to be encoded and who don't need it. If they are passed on the URL (via this API module), then encoding is done automatically. If values are passed in the HTTP body (encoded as JSON), then no encoding is required. I have tested this method and it works fine. It does require to refactor all code and to remove the calls to encodeURLString and decodeURLString (unless in places where URLs are created in code).

I guess we need to go for the proper option in the long-term to reduce the chances of coding issues. This simplifies code and improves code quality and reliability (in the long-term). The same mechanism is used in the Enterprise console, so it should be addressed there too.

[ramondeklein]

There have been issues with encoding in the past (see also #1086), so that's why a custom encoding mechanism is used. The advantage of using base64 is that it won't be automatically decoded in some cases. With encodeURIComponent some libraries may be smart and decode it automatically.

Also there were some issues with the React router that didn't handle encoded parameters correctly. Issue remix-run/history#505 is related to do that. During today's grooming session we decided that we'll investigate if these issues are now resolved.