feat(integrations): add registration display name

[migmartri]

Adds an optional display name to the subscription model that can be used to differentiate different integration instances.

For example, you might perform a registration (chainloop integration add) for an integration that represents a production instance of dep-track while another one will point to staging.

This will be specially relevant when we add new integrations like webhooks in which the webhook URL by itself can not be shown back to the user (since it's a secret). Even if we do, it has no information encoded in itself that indicate its purpose.

Examples

Register integration with optional display name set.

chainloop integration add dependency-track  --instance http://localhost:8081 --allow-project-auto-create  --display-name "my production instance"

┌──────────────────────────────────────┬────────────────────────┬─────────────────┬───────────────────────────────┬─────────────────────┐
│ ID                                   │ DESCRIPTION            │ KIND            │ CONFIG                        │ CREATED AT          │
├──────────────────────────────────────┼────────────────────────┼─────────────────┼───────────────────────────────┼─────────────────────┤
│ be7d1dc6-30b4-4341-ba1a-238e424cc730 │ my production instance │ dependencytrack │ domain: http://localhost:8081 │ 08 Jun 23 18:49 UTC │
│                                      │                        │                 │ allowAutoCreate: true         │                     │
└──────────────────────────────────────┴────────────────────────┴─────────────────┴───────────────────────────────┴─────────────────────┘

The list view also adds the column.

[danlishka]

That makes sense, let me know when this is ready to review

[migmartri]

This is added to the parent command so it can be reused by future integrations

[danlishka]

I am not sure about calling it a display name, this is a bit confusing. Why do we try to call it a displayName in the CLI and use for an integration instance description? Why not just name or description?

[migmartri]

My reasoning is as follows, and sorry I should have given this context before.

The integration model and DB entry describes an integration registration instance and in that context, the description term makes sense, it's a description of the registration entity.

Once we move to the CLI, to the integration add/list command, the description term can be ambiguous, is this the description of the registration or from the actual extension, shown as kind (which will likely have a description in the future). To make things worse I don't think we can call this registration description because the registration term has not been introduced in the UX.

So to summarize, description makes sense once you are in a specific context (db entry) but in the UX where both registration + extension information is shown it can be ambiguous.

That said, for consistency, and so we can tackle this in the future with a broader picture I'll rename this to description as well.

Thanks!

[migmartri]

I renamed name for kind for consistency. I changed it to name in a previous patch but I think it was a mistake, we need to think it through.

[migmartri]

That makes sense, let me know when this is ready to review

@danlishka go for it!

[migmartri]

@danlishka ptal, I renamed the client code displayName.

See this comment for some context so we can re-evaluate it in the future #146 (comment)

[danlishka]

Thanks!