enhancement(lua transform): Support metric events in version 2

[ghost]

This PR adds support for both metrics and log events in lua support APIv2 in accordance to RFC 1999.

The change is not documented because Lua API v2 is not stable yet, so it is not advertised in the documentation.

Closes #1563, closes #1406, and closes #706 (for Lua APIv2).

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**:

• For each failure path, is there sufficient context logged for users to investigate the issue?
• Do the tests ensure that behavior is sane for inputs that don't meet normal assumptions (e.g. missing field, non-string, etc)?
• Did you add adequate documentation?

Files matching src/transforms/**:

• Did you add behavior tests (tests/behavior) that represent the behavior of this change? For example, testing for Vector's field path notation for nested fields.

This is an automatically generated QA checklist based on modified files

[Hoverbear]

Oh no, I hate this. Array indexing is going to be my bane! Hahaha

[ghost]

In principle, it possible to make it zero-based, as Lua arrays are just hash tables with numeric indexes. But third-party Lua libraries might not handle this well.

[Hoverbear]

It's unfortunate we can't make this a match statement to avoid this breaking accidentally in future metric type additions.

[ghost]

I considered devising a serde-style derive macro which would implement FromLua for arbitrary enums, but decided against in the initial implementation because I thought that it might add too much complexity, and also it is not clear what to do with DateTime<Utc> and Bytes because both of these types are external, so FromLua cannot be implemented for them and it has to be worked around somehow.

But doing this this could have solved the issue of possible breaking of this in case if new metric type is added.

[Hoverbear]

Looks good. :) Had a suggestion to improve the error message, but otherwise free to merge.

[binarylogic]

From planning: Adding final touches before merging.

[binarylogic]

@a-rodin we'll need to update the docs before merging this. This will be a little different in that we'll want good examples and properly document the hooks API.

[ghost]

@binarylogic I'll add docs and examples for this.

But I have two questions:

1. Where to put the documentation for version 2 of the transform? Should it be in website/docs/reference/transforms/lua.md.erb or in a separate file?
2. Although this PR doesn't implement hooks, would it make sense to document all parts of RFC 1999 at once, and then just add implementations for them?

[binarylogic]

Where to put the documentation for version 2 of the transform? Should it be in website/docs/reference/transforms/lua.md.erb or in a separate file?

In the same file, no need to create a new one. Take a look at the influxdb_metrics.toml file. Notice the use of groups.

Although this PR doesn't implement hooks, would it make sense to document all parts of RFC 1999 at once, and then just add implementations for them?

It's up to you. I want to discourage our docs from getting ahead of the code. If we want to do it all in one shot then I would merge this, implement the hooks, and then follow it all up with docs.

In general though, we should be encouraging users to use v2 and not v1.

[ghost]

I want to discourage our docs from getting ahead of the code. If we want to do it all in one shot then I would merge this

I would like to proceed this way: implement hooks (at least hooks.process and then add the documentation). The reason is that I want the documentation to display only stable APIs.