enhancement(vrl): RFC for return expression (#19828)

* add rfc with return expression

* Apply suggestions from code review

Co-authored-by: Pavlos Rontidis <[email protected]>

* Add optional parameters to return and explicitly do not support closures

* Remove return without arguments

---------

Co-authored-by: Pavlos Rontidis <[email protected]>

rfcs/2023-02-08-7496-vrl-return.md

@@ -0,0 +1,74 @@
+# RFC 7496 - 2023-02-02 - VRL Return Keyword
+
+Add return expression to the Vector Remap Language.
+
+## Context
+
+- #7496
+
+## Cross cutting concerns
+
+- None.
+
+## Scope
+
+### In scope
+
+- Adding a return expression to VRL.
+- The `return` can optionally take an expression as an argument and the result of that expression will be returned.
+
+### Out of scope
+
+- Adding new keywords for similar purposes such as `drop`.
+- Defining semantics of keywords that are usually used for other purposes in other languages such as `break`.
+- Implementation of `return` expressions inside closures.
+
+## Pain
+
+- Aborting with changing the input cannot be easily done.
+- VRL code is often unnecessarily indented because of lack of early returns.
+
+## Proposal
+
+### User Experience
+
+- A `return` expression causes the VRL program to terminate, keeping any modifications made to the event.
+- A `return` expression must be always followed by another expression, whose value will be used as the emitted event.
+- The keyword cannot be used inside a closure. Trying to do that will result in a compilation error.
+
+### Implementation
+
+- Implementation will be similar to the current `abort` keyword when `drop_on_abort` is set to `false`. The only difference is that the returned value will be taken from the provided expression and not from original input.
+- `drop_on_abort` will have no effect on return calls and configuration such as `drop_on_return` will not be added.
+
+## Rationale
+
+- It will be possible to write VRL with less indentation making it more readable.
+- `return` is already a reserved word so it can be used without introducing a breaking change.
+
+## Drawbacks
+
+- The `return` keyword will be given a semantic meaning that will have to be supported going forward.
+
+## Prior Art
+
+- Most languages have a way to make early returns.
+- There was no prior attempted implementation of returns in VRL to my knowledge.
+
+## Alternatives
+
+- New keywords that are not currently a reserved keyword can be added to the language. This would, however, constitute a breaking change.
+- This feature can also be rejected as it does not add any functionality that cannot be currently expressed.
+
+## Outstanding Questions
+
+## Plan Of Attack
+
+Incremental steps to execute this change. These will be converted to issues after the RFC is approved:
+
+- [ ] Submit a PR with implementation of returns.
+
+## Future Improvements
+
+- Adding a `drop` keyword for explicit drop as an alternative to pre-configured `abort` for full control over passing the events to output unchanged, passing them changed, or routing them to the dropped output.
+- Adding `return` to closures.