Improved the RenderLavaEndpoint command to parse the querystring in the route parameter

[MichaelAllen]

Notice

In case you are submitting a non bug-fix-PR, we highly recommend you to engage in a PR discussion first.

There are many factors we consider before accepting a pull request. This includes:

1. Whether or not the Rock system you run is a standard, main-line build. If it is not, there is a lower chance we will accept your request since it may impact some other part of the system you don't regularly use.
2. Features that would be used by less than 80% of Rock organizations, or ones that don't match the goals of Rock.

With the PR discussion we can assess your proposed changes before you start working on it so that we can come up with the best possible approach to it. This may include:

1. Coming up with an alternate approach that does not involve changes to core.
2. Advising how your proposed solution be done in a different way that is more efficient and consistent with the rest of the system.
3. Have one of our core developers make the changes for you. This may be the case if the change involves intricate tasks like an EF migration or something similar.

Proposed Changes

When using the Render Lava Endpoint command, if you add a query string parameter to the route - it never calls the endpoint. As soon as the query string is removed - the endpoint is called.

This PR updates the RenderLavaEndpoint lava command to allow for query string parameters.

Example:

//- This works
{% renderlavaendpoint route:'^/group-finder/showgroups' %}

//- This does not currently work
{% renderlavaendpoint route:'^/group-finder/showgroups?GroupKey=17MNOZN7yQ' %}

If this PR is accepted, both of the above examples would work, and the query string parameter from the second one would be available to the lava app in the QueryString merge field, just as it would have been if the endpoint were called from an hx-get or similar tag on the page.

Fixes: Triumph-Tech/Triumph-Helix#17

Types of changes

What types of changes does your code introduce to Rock?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality, which has been approved by the core team)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• This is a single-commit PR. (If not, please squash your commit and re-submit it.)
• I verified my PR does not include whitespace/formatting changes -- because if it does it will be closed without merging.
• I have read the Contributing to Rock doc
• By contributing code, I agree to license my contribution under the Rock Community License Agreement
• Unit tests pass locally with my changes
• I have added any required unit tests or integration tests that prove my fix is effective or that my feature works
• I have included updated language for the Rock Documentation (if appropriate)

Further comments

This thread in Rocket.Chat does a good job of explaining one possible use case for this.

In one GET endpoint (/my-app/groups), I'm trying to call another endpoint (/my-app/group). In groups endpoint, I loop on the actual set of groups, and have this in the for loop {% renderlavaendpoint route:'^/my-app/group?GroupGuid={{ groupGuid }}' %}

To not repeat code, I was hoping that the groups endpoint could loop on all the guids and use the group endpoint for each.
Doing the "call" to the group endpoint via an hx-get attribute of an element, results in the browser doing all the Ajax calls.

If, instead, the {% renderlaveendpoint %} could be used in the groups endpoint, then there is no API calls from the browser, because it would all occur internal, server-side...

If I had 100 groups to show, using the hx-get approach, results in 1+100 API calls from the browser.
If renderlavaendpoint worked [with querystring params], that is 1 call, because groups returns the content from all the group calls in one shot.

Documentation

In the documentation for this lava command, we could add an example showing a querystring. Maybe something like this:

If you include query string parameters in the route, they will be made available to your lava application in the QueryString merge field.

{% renderlavaendpoint route:'^/group-finder/showgroups?GroupKey=17MNOZN7yQ' %}

Migrations

If your pull request requires a migration, please exclude the migration from the Rock.Migration project, but submit it with your pull request. Please add a note to your pull request that provides a heads up that a migration file is present.