[tt-1924] Go plugins per method and path

[joshblakeley]

Description

Allows a Tyk user to run a different Go function in every single possible part of their API if they should want to. Can be a high performance replacement for the JSVM virtual endpoints.

Think of it as having either as many native Go lambda style functions inside the Gateway available to you as you want, or if you want, unlike existing JS virtual endpoints, requests pass through to real upstreams and you just get the extra flexibility of this setup.

Related Issue

Internal ticket viewable here https://tyktech.atlassian.net/browse/TT-1924

Motivation and Context

Our virtual endpoints are really well loved by users but have some issues with high performance scenarios. Go plugins are the most native way to inject extra code into the API Gateway. Previous there were set hooks that a plugin function could sit and every request would route through it.

This PR makes it so that the Go plugins can be loaded per path and method using the usual API designer definitions.

Users can utilise this in a few different ways:

• A single Go plugin file shared object with multiple handlers that can be called from various APIs
• Many shared objects each referenced from different plugins.

Both cases are handled and users can mix and match depending on their complexity and code ownership.

How This Has Been Tested

See the /test/goplugin folder for function examples.

In your API definition set up your per path/method goplugin functions as an array of config blocks just like any other API designer middleware.

Functions can all be in a single file or be pulled in from various files.

The same rules apply as with the existing go plugins and we recommend using the Go Plugin compiler container to help you create the shared objects that are guaranteed to work with a particular gateway version.

... 
"extended_paths":  {
            "go_plugin": [
                  {
                "plugin_path": "../test/goplugins/goplugins.so",
                "path": "/get",
                "method": "GET",
                "func_name": "MyPluginPerPathFoo"
              }
             ]
          }
...

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own
  fork, don't request your master!
• Make sure you are making a pull request against the master branch (left side). Also, you should start
  your branch off our latest master.
• My change requires a change to the documentation.
  • If you've changed APIs, describe what needs to be updated in the documentation.
  • If new config option added, ensure that it can be set via ENV variable
• I have updated the documentation accordingly.
• Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• When updating library version must provide reason/explanation for this update.
• I have added tests to cover my changes.
• All new and existing tests passed.
• Check your code additions will not fail linting checks:
  • go fmt -s
  • go vet

[sredxny]

LGTM! amazing job

[tbuchaillot]

Looks good!

[tbuchaillot]

/release to release-3

[tykbot]

Working on it! Note that it can take a few minutes.

[tykbot]

@tbuchaillot Succesfully merged bf5ddd0c3a381e97782b734033b80561d439b0d5 to release-3 branch.