Live Metrics Filtering: Part 1 of 5 - port filtering functionality

[harsimar]

Description

This PR includes:

• Port functionality from filter.ts in node repo to Filter.java. This is responsible for filtering any telemetry item.
• New types: TelemetryColumns & it's child classes. These exist to make filtering easier - instead of using TelemetryItems directly, needed some fields to be boolean or numeric.
• Added a function for parsing timestamps from filtering configuration (it's in a different format than whats in FormattedDuration.java)
• Added util function for converting FormattedDuration string back to microseconds, for filtering of durations.
• Added unit tests for Filter.java & the util function

None of this new code is actually used in the QuickPulseDataCollector yet - that's for a future PR.
Spec: https://github.com/aep-health-and-standards/Telemetry-Collection-Spec/blob/main/ApplicationInsights/live-metrics-filtering.md

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• [] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[azure-sdk]

API change check

API changes are not detected in this pull request.

[jeanbisutti]

Several classes seem to define a mapping between a column name and a colum value, and provide a way to retrieve the mapping value.

The code could be written in this way:

public class RequestDataColumns {
    
    private static final Map<String, Object> mapping = new HashMap<>();

    public RequestDataColumns(RequestData requestData) {
        mapping.put(KnownRequestColumns.URL, requestData.getUrl());
        ...
    }

    public <T> T getValue(String fieldName, Class<T> type) {
        return type.cast(mapping.get(fieldName)) ;
    }
}

To use this code:

String urlValue = requestDataColumns.getValue(KnownRequestColumns.URL, String.class);

This code is less boilerplate (less else if branches). The disavantage is that it that it induces boxing in the constructor with primitive column types. How often objects such as RequestDataColumns would be created?

If KnownRequestColumns would be an enum and not a list of String constants, getValue would become:

public <T> T getValue(KnownRequestColumns fieldName, Class<T> type) {
        return type.cast(mapping.get(fieldName)) ;
    }

So, you could not use getValue with any String / column type. The code would be less prone to programmatic mistakes.

[jeanbisutti]

I have approved with some comments.

It would be great if you could address them in this PR or a follow up one.

As discussed, we may revisit this code later after other PRs are merged.

[harsimar]

I have approved with some comments.

It would be great if you could address them in this PR or a follow up one.

As discussed, we may revisit this code later after other PRs are merged.

I will merge for now and address comments in following PR - we can always go back and reflect on content from this PR when we need to.