Add better controls for emitting ECHConfigs in retry_configs

[sftcd]

As raised by @gstrauss we could do with some better controls here.

One idea is to add another input to the flush() function that says to disable
for_retry for the matching ECHConfigs.

Note: This issue is really about the ECHStore APIs that are part of the feature branch, but this seems a better place to record the issue as it'll be a couple of PRs ahead in the feature branch plan before I address this.

[gstrauss]

When refreshing keys periodically, e.g. to add newly generated keys, there should be a way to unset the for_retry flag for existing keys for which a newer key exists (or will exist).

A simple way would be an interface to unmark for_retry for all keys in the OSSL_ECHSTORE before new keys are added. I think that is what you are suggesting above for OSSL_ECHSTORE_flush_keys: flush keys that have expired and have a flag for whether or not to also unmark for_retry on remaining keys (not flushed). This might be imprecise if some keys get updated in a certain timeframe, and other keys get updated in a different timeframe.

A less-efficient way -- but more precise -- might be to unmark for_retry for all existing keys with the same public_host when a new key is added, though the underlying OSSL_ECHSTORE data structure is not organized for an efficient lookup of public_host.

Aside: OSSL_ECHSTORE_flush_keys should not return an error if there are no keys in the OSSL_ECHSTORE.

[sftcd]

We're looking now at how to best handle the CI setup we have at https://github.com/defo-project now that lighttpd has ECH code in upstream and we're still in the process of getting ECH server code merged with the openssl feature branch. Once we have something sorted there (next few days hopefully) we can address these issues in those builds and feed any changes into PRs for openssl as/if needed.