feat(easm): add EASM source integration

[alexpederneschi]

Hello,

What this PR is for?

Adds a new source that integrates EASM scan results into the Catalog. It reads a customer's latest completed run from the backend endpoint as a single cursor-paginated list of items, each tagged with a type discriminator (domain, host, ip, endpoint, vulnerability), and emits one source.Data per item.

Includes:

• internal/source/easm/ with client, env config, and the SyncableSource implementation.
• Wiring in internal/cmd/common.go to register the easm source.
• Example ItemTypeDefinitions and mappings under docs/examples/easm/.

Note: This PR does not include tests yet.

[giulioroggero]

Thanks, we will verify the new connector soon

[albertocaminati]

Review

Base answer

Hi, first of all, thank you for your first contribution!
I'll send you a review with all the changes needed.

Resources and Docs

Docs

I would ask you to add a docs that will be used to configure correctly the new source (like in 'docs/how-to' for the existing sources).

ITDs

The group of the ITDs cannot be mia-platform.eu, this is reserved to the one automatically seeded by the Catalog. A possible value you could use is unguess.io.
This also reflects on the filenames of the single ITDs, e.g. easm.unguess.io.domains.yaml or domains.easm.unguess.io.yaml (the second is more intuitive explicitating the resource name on the left).
The version is preferable to be v1 since we have also moved on from v1alpha1, unless you specifically wanted it to be an alpha.
About the spec.names it is needed to add singular and displaySingular.

Mappings

Both the points of group and version apply here too. Thus for apiVersion all combined could become unguess.io/v1.

Resource Files Location

More in general I would ask you to move all the above resources respectively in the following directories:

• docs/external-sources/easm/how-to/010_easm-source.md
• docs/external-sources/easm/mappings/*
• docs/external-sources/easm/itds/*

Missing tests

I saw the tests are completely missing at the moment, can you add them for your new developed source?
Without tests with a meaningful coverage this PR cannot be merged by our contributing guidelines.
My advice is to run them using the already prepared command from the Makefile, since they then matches with the CI:

# Clean all artifacts for clean test run
make clean-all

# Linting
make lint

# Tests with race conditions and coverage check
make test-coverage

Code & Style

It seems ok and in line with the rest of the ibdm project.

[alexpederneschi]

Thank you for the review. We've gone through all the points, here's what was changed.

Docs

I added docs/external-sources/easm/how-to/010_easm-source.md, following the same structure and style as the existing sources in docs/how-to.

ITDs

I changed the group to easm.unguess.io and renamed the files accordingly to the resource-name-left form (domains.easm.unguess.io.yaml, etc.). The version is now v1, and I added singular and displaySingular to spec.names. The top-level apiVersion is now easm.unguess.io/v1 as well.

Mappings

The apiVersion in all mappings is now easm.unguess.io/v1, consistent with the ITD group and version.

Resource Files Location

Everything is now under docs/external-sources/easm/{itds,mappings,how-to}/ as requested.

Tests

I added a full test suite under internal/source/easm/. The only make lint failure is a pre-existing, unrelated nolintlint issue in internal/mapper/functions/objects.go, no EASM code involved.