Add feature flag for enabling Mbed TLS support

[sgoll]

Description

This adds a feature flag mbedtls that builds open62541 with Mbed TLS support for encryption. We bundle the Mbed TLS sources alongside the sources of open62541 to support all existing build targets.

[sgoll]

This builds on #37 and #38 and should only be merged afterwards.

[sgoll]

We bundle the Mbed TLS sources alongside the sources of open62541 to support all existing build targets.

We should eventually revisit this decision. We could try to move the bundled source code into separate crates to reduce the crate size when encryption support is not actually needed.

[sgoll]

This and other parts of the code prepare for the eventual introduction of OpenSSL support as well, but for now I am reluctant to enable this because it requires further tests—and we can probably not bundle OpenSSL as well, so that the set of target platforms will probably be a reduced on, on a best-effort basis. Not ideal.

[uklotzde]

We bundle the Mbed TLS sources alongside the sources of open62541 to support all existing build targets.

We should eventually revisit this decision. We could try to move the bundled source code into separate crates to reduce the crate size when encryption support is not actually needed.

Sound like a plan. The size of this crate is already huge.

How much does the package size increase when adding mbed TLS?

[sgoll]

How much does the package size increase when adding mbed TLS?

• Before (1fdb3c4): Packaged 350 files, 7.5MiB (1.1MiB compressed)
• With this PR: Packaged 713 files, 15.7MiB (2.6MiB compressed)

So we are more or less doubling the package size.

[uklotzde]

Adding this feature is convenient.

But is it worth the huge increase in package size? Each update of either open62541 or mbedtls will create a new BLOB with lots of redundant/unchanged data.

[sgoll]

But is it worth the huge increase in package size? Each update of either open62541 or mbedtls will create a new BLOB with lots of redundant/unchanged data.

That is correct. My plan is to integrate encryption support first in a way that works, then look for any other issues that we might need to solve to get encrypted OPC UA communication working in Rust. When this sort-of proof of concept is okay, we can try to split off the bundled source code into separate crates.¹

Footnotes

1. I have no idea how that will work out but I would like to solve this problem separately. ↩

[uklotzde]

Let's start with this baseline.