feat(coral): Improve promotion information for schema

[programmiri]

About this change - What it does

• adds a shared component PromotionBanner to be used for topics as well as schemas
  • PromotionBanner takes the PromotionStatus as well as hasOpenRequest and based on that decides what to show. It's up to the components using PromotionBanner to decide if it should not be rendered at all because the user is not topicOwner
  • it takes topicName as explicit prop. The topicName is available on promotion details for topics, but not for schemas.
• updated TopicPromotionBanner to use PromotionBanner internally.
  • TopicPromotionBanner is responsible for passing the right promote element (which differs for topic and schema) as well as passing the right properties through. I left this as a separate component because that way it is easier to tests this well without making the tests for TopicOverview more complex. I used a data-testid to enable easier testing in TopicOverview.
• I updated the test in TopicOverview to not only use snapshots but confirm the rendering/absence of banner explicitly.
• added SchemaPromotionBanner with use of PromotionBanner internally (same explanation as above)
• updated TopicDetailsSchema to use the new component

Note:

There will be a follow up by backend to add hasOpenSchemaRequests to topicInfos, matching the existing properties. For now, we can check for hasOpenRequest && !hasOpenACLRequest && !hasOpenTopicReques -> if hasOpenRequest is true but hasOpenAclRequest and hasOpenTopicRequest are both false, the only open request is a schema request.

Doing a small follow up for this change does remove pressure from backend to do that urgently. We also don't need to wait for the BE change to be merged (and for testing stating to be updated).

[mathieu-anderson]

Just a few comments ^^ Not sure if adding support for connector promotion is premature optimisation or forward thinking haha

[mathieu-anderson]

👍

Awaiting more changes

[mathieu-anderson]

I expect errorMessage is not optional because we often store error messages in a local state initialized with "" ? I'm thinking that often this could be avoided by using directly the error and isError returned by useMutation, and would maybe be a bit clearer?

This is definitely not in scope of this PR, but maybe it would be nice as a folow up? "Standardized mutation error handling"?

[programmiri]

"errorMessage" in this case is optional because for example TopicPromotionBanner does not have the need to show an error message. And if we use update this promotion banner to be more generic (e.g. also be used for claim) there may be cases where we need to be able to show an error here, but in most cases the "button" links to a form, which has it's own error handling.

"Standardized mutation error handling"?

We could do that, but for this component I don't think that we should assume that the error shown here is a mutation error. It is currently in the one use case, but it could also be a different kind of error. And tying or components too closely to structures of libs we're using may restrict us a bit. What if we want to / need to get rid of react-query -> or console wants to use components from us and they don't use react-query.

[mathieu-anderson]

👍