VRL `Target` methods should be infallible

[fuchsnj]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Use Cases

Today, the Target trait has 4 methods.

    fn target_insert(...) -> Result<(), String>;
    fn target_get(...) -> Result<Option<&Value>, String>;
    fn target_get_mut(...) -> Result<Option<&mut Value>, String>;
    fn target_remove(...) -> Result<Option<Value>, String>;

All four of these are fallible, however none of the implementations should actually be able to fail at runtime. The VRL type system expects these to always succeed, so any failures can result in invalid type definitions. All of these functions should be modified to be infallible.

There are some places these can still fail at runtime, but the errors are just silently ignored. This is mostly around metrics insertion. This can be solved by adding more compile-time type information to move the errors to compile-time (such as defining "assignable types" and only allowing assignments that match the correct type)

Version

0.23.0

[jszwedko]

The bulk of the work here is adding type information for metrics so that we can have compile-time errors. After that it should be relatively simple to drop the Results here.

[fuchsnj]

This will require work in both VRL and Vector.

• VRL needs to add support for more type information to know if certain types can be assigned to certain paths of a target
• Vector needs to implement those new types for metrics

[fuchsnj]

This can cause invalid type definitions which could result in a panic.
An example panic was found in Vector: vectordotdev/vector#17217