🔥 [#2] Drop (unintended) support for cosign registration attribute

This snuck in accidentally because the component inherits from the
email component in the implementation, but it was not a conscious
decision.

This does *not* make it impossible to send the data to StUF-ZDS, ZGW
APIs or Objects API integration as the unmapped data is included by
default in some form anyway or there are existing mechanisms to
include it via custom data templates.

src/formio/components/cosign.ts

@@ -43,7 +43,7 @@ export interface CosignV1ComponentSchema extends Omit<CosignV1InputSchema, KeysT
   authPlugin: string; // plugin identifiers in the backend are dynamic
 }
 
-type V2KeysToOmit = 'hideLabel' | 'disabled' | 'placeholder';
+type V2KeysToOmit = 'hideLabel' | 'disabled' | 'placeholder' | 'registration';
 
 /**
  * The cosign component type, otherwise known as 'Cosign'.

test-d/formio/components/cosign-v2.test-d.ts

@@ -51,10 +51,6 @@ expectAssignable<CosignV2ComponentSchema>({
     // translatedErrors is converted into errors by the backend
     required: 'Je moet een waarde opgeven!!!',
   },
-  // registration tab in builder form
-  registration: {
-    attribute: '',
-  },
   // translations tab in builder form
   openForms: {
     translations: {
@@ -114,3 +110,16 @@ expectNotAssignable<CosignV2ComponentSchema>({
   authPlugin: 'digid',
   confirmationRecipient: true,
 });
+
+// registration attributes are not supported
+expectNotAssignable<CosignV2ComponentSchema>({
+  id: 'yejak',
+  type: 'cosign' as const,
+  validateOn: 'blur' as const,
+  key: 'someCoSign',
+  label: 'Some cosign',
+  authPlugin: 'digid',
+  registration: {
+    attribute: 'foo',
+  },
+});