config_format: yaml: Support passing arbitrary objects to processors

[tchrono]

This was initially based on
#8656 and #8661 but ended up making few different choices:

• Instead of adding FLB_CONFIG_MAP_KVLIST and FLB_CONFIG_MAP_ARRAY as config map types, it adds a single FLB_CONFIG_MAP_VARIANT which accepts an array or map. The passed array/map can have nested values and accept any JSON/YAML types, which are converted to cfl types. The processor will simply receive a cfl_variant pointer and is responsible for releasing the memory later.
• The existing flb_config_map_set function is reused by passing the cfl_variant pointer (from the yaml parsing phase) as the value of a flb_kv. Then pointer is eventually moved into the processor context.

I have added an example processor which uses the new feature, here's a config that can be used to test it:

service:
    flush: 0.2
    log_level: info

pipeline:
    inputs:
        - name: event_type
          tag: event
          type: logs
          processors:
            logs:
              - name: log_replacer
                replacement:
                  some_extra_data:
                    some_string: "hello world"
                    unquoted_literals:
                        - some_int: 4
                        - some_float: 3.1
                        - some_bool: true
                    quoted_literals:
                        - some_quoted_int: "4"
                        - some_quoted_float: '3.1'
                        - some_quoted_bool: "true"

    outputs:
        - name: stdout
          format: json
          match: event

This example processor is optional and required some small changes to the CFL library. I only put this processor to make it easier testing the new YAML feature. I can also remove this example processor (and the CFL changes) before it is merged.

Here's a command to run it locally and demonstrate the yaml parsing using JSON syntax highlighting:

/build/bin/fluent-bit -c log-replacer.yaml | jq '.'

@pwhelan @cosmo0920

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• Example configuration file for the change
• Debug log output from testing the change

• Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

• Run local packaging test showing all targets (including any new ones) build.
• Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• Documentation required for this feature

Backporting

• Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[cosmo0920]

Could you submit your cfl patches into https://github.com/fluent/cfl repo?

[tchrono]

Could you submit your cfl patches into https://github.com/fluent/cfl repo?

@cosmo0920 I'm not certain these patches are a good idea. I only did this as a quick workaround to allow both the processor plugin and the engine to have a reference to the same values (shared ownership doesn't seem such a good idea in this case).

I can imagine two better solutions to the problem:

• allow a CFL object to have a refcount. cfl_variant_destroy decreases the refcount and frees the memory when it reaches 0
• a new return code to processor plugins, which tells the engine to not free the CFL object when it converts back to msgpack.

In any case, would be better to do this separately from the yaml-specific changes. I can remove the last two commits of this PR so we can merge without CFL changes. What do you think?

[cosmo0920]

• allow a CFL object to have a refcount. cfl_variant_destroy decreases the refcount and frees the memory when it reaches 0

I like this option if applicative this selection should make to be able to implement another place to handle the reference and malloc/free management.

a new return code to processor plugins, which tells the engine to not free the CFL object when it converts back to msgpack.

Not sure we could implement this mechanism. Because all of hot-reloading should be completed in flb_reload.c.

[tchrono]

As discussed privately with @cosmo0920 , I have removed the example processor and CFL changes since they belong in a different PR

[edsiper]

I see some comments from @pwhelan on this one, are we expecting more changes or a different proposal ?

[edsiper]

ping @pwhelan

[pwhelan]

LGTM