Stub-out assorted functions for haproxy

[ctz]

In pursuit of #62

[djc]

What's the process here? This helps the target app compile and then you can figure out which ones are actually called?

[ctz]

What's the process here? This helps the target app compile and then you can figure out which ones are actually called?

Not actually recompiling the target app; this is a link-time replacement library (in other words, the application is already compiled against OpenSSL 3, and the goal is to work with it as-is.)

The process is something like:

1. Run the target executable and capture logs from the dynamic linker. This data goes into the "haproxy" column of https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md . It is a list of all the symbols haproxy requires from libssl.so in order to dynamically link. That was Add haproxy 2.8.5-1ubuntu3.3 to compatibility matrix #72

2. Look at https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md and choose a line where the "haproxy" column is checked, but the "implemented?" is empty. Each such line would mean haproxy will fail to dynamically link, and you'll get an error like "haproxy: symbol lookup error: haproxy: undefined symbol: SSL_set_client_CA_list, version OPENSSL_3.0.0"

3. Work out what that symbol does and how haproxy uses it; consulting openssl documentation and haproxy source.

4. The function can be stubbed if haproxy is pretty happy if the function just returns an error, or the function has no observable effect, or is peripheral to other APIs that are also stubs, etc.

   eg, in this PR SSL_SESSION_get_max_early_data has a documented base case of returning zero (meaning early data is disabled) so that works logically for now.

[djc]

What's the process here? This helps the target app compile and then you can figure out which ones are actually called?

Not actually recompiling the target app; this is a link-time replacement library (in other words, the application is already compiled against OpenSSL 3, and the goal is to work with it as-is.)

The process is something like:

1. Run the target executable and capture logs from the dynamic linker. This data goes into the "haproxy" column of https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md . It is a list of all the symbols haproxy requires from libssl.so in order to dynamically link. That was Add haproxy 2.8.5-1ubuntu3.3 to compatibility matrix #72

2. Look at https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md and choose a line where the "haproxy" column is checked, but the "implemented?" is empty. Each such line would mean haproxy will fail to dynamically link, and you'll get an error like "haproxy: symbol lookup error: haproxy: undefined symbol: SSL_set_client_CA_list, version OPENSSL_3.0.0"

3. Work out what that symbol does and how haproxy uses it; consulting openssl documentation and haproxy source.

4. The function can be stubbed if haproxy is pretty happy if the function just returns an error, or the function has no observable effect, or is peripheral to other APIs that are also stubs, etc.
   eg, in this PR SSL_SESSION_get_max_early_data has a documented base case of returning zero (meaning early data is disabled) so that works logically for now.

Is something like this comment already in something like a CONTRIBUTING.md or somewhere else permanent? Would be useful IMO.