Add a proper dependency to the `jakarta.el` API to reduce maintenance efforts

[tasso94]

Context

• The source code of the API javax.el is part of our codebase.
  • Cf. https://github.com/camunda/camunda-bpm-platform/tree/master/engine/src/main/java/org/camunda/bpm/engine/impl/javax/el
  • This comes from copying the source code of de.odysseus.juel:juel-impl and de.odysseus.juel:juel-api (a copy of Sun Microsystems Inc. Expression Language 2.2) into our codebase
  • Cf. https://github.com/beckchr/juel/blob/master/modules/api/pom.xml#L30-L32
• This is problematic since we ...
  • ... don't have good test coverage for the dependency, which leads to regressions if we change something.
  • Examples of regressions:

    • 2848

    • https://jira.camunda.com/browse/CAM-14916
  • ... cannot easily update the version and benefit from bug fixes.
  • Examples of bugs that have already been fixed in newer versions:
    • https://jira.camunda.com/browse/CAM-14673
    • https://jira.camunda.com/browse/CAM-14684

    • 3053

Acceptance Criteria (Required on creation)

• The source code of javax.el is replaced by a proper dependency (e.g., jakarta.el:jakarta.el-api).
• The source code of de.odysseus.juel:juel-impl is either replaced by a proper dependency or moved into a dedicated module form where it can be consumed by all of our components (bpmn engine, dmn engine, quarkus extension).
  • Keeping the JUEL source code has the advantage that we can still benefit from customizations, and we can make it compatible with jakarta.el:jakarta.el-api (Odysseus JUEL is not maintained anymore).
• We fully understand the impact (e.g., potentially changed behavior of expression resolution, integration with application servers/runtimes).

Hints

• Breaking changes
  • Accessors that extend an anonymous class are not accessible (cf. https://github.com/camunda/camunda-bpm-platform/pull/3013/files#diff-4282132fb7919838c58947bf6c4ff413b488dcd733d24195baf08464bdb46741)
  • ~Recently implemented fix #2848 doesn't work with a proper dependency to jakarta.el:jakarta.el-api~ This works with EL API 4.0 and 5.0 out of the box, since parameter types are derived from all parameter values, nulls are considered assignable to the defined method parameter type and methods are found correctly
  • ~This is most likely because of the following change between Java EL 2.2 and 3:~

    The default coercion for nulls to non-primitive types returns nulls. For instance, a null coerced to String now returns a null, instead of an empty String. – cf. pg. 62 in ELSpec.book

  • Bean method invocation changes - method parameters are converted by the resolver as described in the EL API specification. As a result, null values will be coerced into the type defined by the method. For example, calling myBean.setStringAttribute(null), requiring a String parameter, leads to null being coerced into "".
  • Currently, null is passed on as is, even for String types. This is not EL specification-conform anymore with EL API 2.2+
• Effort: M

Links

• Prototypical spike: https://github.com/camunda/camunda-bpm-platform/pull/3013
  • Out of scope
  • Application server support
  • Shading