Interface definition for the collector config management in query service

[srikanthccv]

Some prior context:

• This PR https://github.com/SigNoz/signoz/pull/1787 contains OpAMP server implementation that persists in the current effective config for the collector. It also pushes the random updates for timeout to verify the OpAMP Client functionality.

• This repo https://github.com/SigNoz/signoz-collector-config-parser/ shows how to parse the byte string config and manipulate config at a minute level.

The original goal is to enable certain use cases that require the collector to work with the new config. Any work that will be done around this needs a way to represent the config both on the frontend and backend. Would you want to define your own types/structs that match the component's config? Or would you rather rely on the upstream config? The former can be a lot of maintenance burden since tens of components change for each release and need to be synced. We could build a tool that generates the types for both backend and frontend by parsing the collector config.

There is also a need for a common interface definition for doing CRUD on the config so that each individual does not need to repeat the same stuff. This works as a bridge b/w query service components and OpAMP.

Please add the use cases that should be covered and anything else that might be relevant here.

[mindhash]

Use cases for Drop rules:

• Ability to add/edit filter processor in existing pipelines. A processor may be tied to a specific exporter + receiver combo. It might help if we can tag each pipeline uniquely

Use cases for Sampling rules:

• same as drop rules
• Ability to update params for a specific sampling processor - which may be combination of filter + sampling processor.
• batch update different sections of config file at once for atomicity