Porting ENTMQBR-3372 to operator-lts

AMQ 7.5 installed via operator intermittently fails with the message

Using acceptors from environment and removing existing entries
sed: -e expression #1, char 330: unknown option to `s'
Appending connectors from environment

After enabling SCRIPT_DEBUG to true, the log shows

+ sed -i '/<\/acceptors>/ s/.*/<acceptor name="amqps">tcp:\/\/ACCEPTOR_IP:5671?protocols=AMQP;sslEnabled=true;keyStorePath=\/etc\/test-amqps-secret-volume\/broker.ks;keyStorePassword=NAAABVSDFDTNIZ64ls3bn40/xIGHRxg3Ry1UwEL;trustStorePath=\/etc\/test-amqps-secret-volume\/client.ts;trustStorePassword=ALV/jjbX3tB8X8NiE2ai6IGphdL6oXoW;enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA;enabledProtocols=TLSv1,TLSv1.1,TLSv1.2;needClientAuth=true;wantClientAuth=true;verifyHost=true;sslProvider=JDK;sniHost=localhost;anycastPrefix=jms.topic.;multicastPrefix=\/queue\/;tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;useEpoll=true;amqpCredits=1000;amqpMinCredits=300<\/acceptor><acceptor name="scaleDown">tcp:\/\/ACCEPTOR_IP:61616?protocols=CORE;tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;useEpoll=true;amqpCredits=1000;amqpMinCredits=300<\/acceptor>\n&/g' /home/jboss/amq-broker/etc/broker.xml
sed: -e expression #1, char 205: unknown option to `s'

The problem is caused by bad escaping. Namely, the base64-encoded keyStorePassword and trustStorePassword values contain "/" (valid base 64 characters) which are NOT escaped – this causes sed to treat the occurrences as the end of the replacement text.

Therefore, the error message "unknown option to `s'" is specifically referring to the sequence "...keyStorePassword=NAAABVSDFDTNIZ64ls3bn40/x..." (i.e. the "/x" is the "unknown option").

Some more background and workarounds:

(1)
Even when using the AMQ 7.5 Broker operator, there is a significant amount of manual command execution required. It is valuable to script these steps in a consistent manner so that development teams may have homogenous local development environments (e.g. using crc) but also so that we have a "verified" sequence of steps to execute in standing up new OCP clusters.
As part of this scripting process, various passwords (like the key & trust store passwords) should ideally be generated. For example, I will typically use a scripted command like `dd if=/dev/urandom bs=24 count=1 2>/dev/null | base64` or `openssl rand -base64 24` to generate random passwords... and this is precisely what triggered the bug in ENTMQBR-3372 since the output of those commands will frequently produce a "/" character in their output.

(2)
The workaround was quite simple: I am now additionally piping the result of either command through sed or tr so that I can either remove or replace the non-alphanumeric Base64 characters.
Examples:

$ dd if=/dev/urandom bs=24 count=1 2>/dev/null | base64 | tr '+/=' '-_%'
$ openssl rand -base64 24 | sed 's/[+/=]//g'