The fact that the non-ISO login options were available in the
demo labeled ISO was just confusing.

Also set up the infastructure to apply patches, and applied at least one patch to start with.

Changed the nodered flow to use the appropriate case for the
payment method.

Testing done:
- Ran `bash demo-iso15118-2-ocpp-201.sh -3`
- Plugged in with PnC
- Charging started

Signed-off-by: Shankari <[email protected]>

Before this, if we wanted to make changes to the demo, we
used to comment code in/out. Let's make those switches
available as command line arguments to avoid editing the
script constantly.

Testing done:
- Ran `bash demo-iso15118-2-ocpp-201.sh -r $PWD -1`
- and `bash demo-iso15118-2-ocpp-201.sh -r $PWD -1 -m` and
  everything launched both times.

Signed-off-by: Shankari <[email protected]>

The citrine setup scripts are already pulled out,
pulling out maeve as well to prep for a more significant
refactor later.

Testing done:
`bash demo-iso15118-2-ocpp-201.sh -r $PWD -3 -m` and
successfully connected to maeve

```
2024-11-11 21:59:26.836301 [INFO] ocpp:OCPP201     :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 3
2024-11-11 21:59:26.886329 [INFO] evse_security:E  :: Requesting key/pair: CSMS
2024-11-11 21:59:27.216402 [INFO] ocpp:OCPP201     :: OCPP client successfully connected to TLS websocket server
2024-11-11 21:59:27.228421 [INFO] ocpp:OCPP201     :: Received BootNotificationResponse: {
    "currentTime": "2024-11-11T21:59:27.000Z",
    "interval": 300,
    "status": "Accepted"
}
with messageId: 9327a063-11c5-4946-9ec4-96631fd09adb
```

Signed-off-by: Shankari <[email protected]>

To simplify the script and make it easier to refactor.

Testing done:
- maeve starts up and the manager connects to it
- citrineos does not start up, but that is unchanged from the
  main branch

Will punt on debugging citrineos until we have rolled forward

- maeve testing

```
2024-11-11 22:43:40.693974 [INFO] ocpp:OCPP201     :: Using certificate: "/ext/source/build/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem"
2024-11-11 22:43:40.694660 [INFO] ocpp:OCPP201     :: Using key file: "/ext/source/build/dist/etc/everest/certs/client/csms/CSMS_LEAF.key"
2024-11-11 22:43:40.701120 [INFO] evse_security:E  :: Building new certificate hierarchy!
2024-11-11 22:43:40.780705 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/ext/source/build/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-11-11 22:43:40.737677 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /ext/source/build/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-11-11 22:43:40.823477 [INFO] evse_security:E  :: Requesting certificate file: [CSMS] file:"/ext/source/build/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
2024-11-11 22:43:40.909915 [INFO] evse_security:E  :: Requesting key/pair: V2G
2024-11-11 22:43:40.913828 [INFO] evse_security:E  :: TPM Key: false
2024-11-11 22:43:40.924600 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-11-11 22:43:40.927839 [INFO] ocpp:OCPP201     :: OCPP client successfully connected to TLS websocket server
2024-11-11 22:43:40.940441 [INFO] ocpp:OCPP201     :: Received BootNotificationResponse: {
    "currentTime": "2024-11-11T22:43:40.000Z",
    "interval": 300,
    "status": "Accepted"
}
with messageId: 351ad980-332b-4c63-9ba4-0a1a07250928
```

- citrine testing

```
Cloning EVerest from /Users/kshankar/Desktop/data/joet-everest/everest-demo into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/everest-demo
Cloning CitrineOS CSMS from https://github.com/citrineos/citrineos-core.git into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms and starting it
Cloning into 'citrineos-csms'...
remote: Enumerating objects: 16467, done.
remote: Counting objects: 100% (303/303), done.
remote: Compressing objects: 100% (221/221), done.
remote: Total 16467 (delta 139), reused 161 (delta 70), pack-reused 16164 (from 1)
Receiving objects: 100% (16467/16467), 5.06 MiB | 2.60 MiB/s, done.
Resolving deltas: 100% (10384/10384), done.
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt
Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms/Server/data/certificates
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms/Server /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.khZGzAKt
```

Citrine failure on both main and this branch

```
127.9 npm verbose exit 0
127.9 npm info ok
131.7 npm verbose exit 1
131.7 npm verbose code 1
------
failed to solve: process "/bin/sh -c npm install --workspaces --verbose && npm run compile --workspaces --verbose" did not complete successfully: exit code: 1
Failed to start CitrineOS.
```

Signed-off-by: Shankari <[email protected]>

Before this change, the citrine and maeve parts of the demo
were essentially copies of each other - they performed very
similar tasks but due to subtle differences, the steps were
long if-guarded blocks of code.

This commit builds on 2a82485
and 821ac3c to identify the
common tasks and pull them out into separate scripts. The
tasks then represent a "CSMS access layer" or common
interface. The details of the CSMS are hidden from the
top-level demo script.

Support for other CSMSes can be added by adding a new
directory and implementing these scripts.

Testing done:

- With the build and run commands in the script commented out
  and exiting right after "start the CSMS"

<details>
<summary>Maeve</summary>

```
Cloning into 'maeve-csms'...
remote: Enumerating objects: 3775, done.
remote: Counting objects: 100% (1108/1108), done.
remote: Compressing objects: 100% (362/362), done.
remote: Total 3775 (delta 853), reused 886 (delta 742), pack-reused 2667 (from 1)
Receiving objects: 100% (3775/3775), 1.30 MiB | 511.00 KiB/s, done.
Resolving deltas: 100% (2700/2700), done.
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA/maeve-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA
Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA/maeve-csms/config/certificates
Validating that the certificates are set up correctly
config/certificates/csms.pem: OK
Chain:
depth=0: CN=host.docker.internal, O=EVerest, C=DE, DC=CPO (untrusted)
depth=1: CN=CPOSubCA2, O=EVerest, C=DE, DC=V2G (untrusted)
depth=2: CN=CPOSubCA1, O=EVerest, C=DE, DC=V2G (untrusted)
depth=3: CN=V2GRootCA, O=EVerest, C=DE, DC=V2G
Patching the CSMS to enable EVerest organization
patching file docker-compose.yml
Patching the CSMS to enable local mo root
patching file 'config/manager/config.toml'
Patching the CSMS to enable local mo root
patching file 'manager/handlers/ocpp201/authorize.go'
Build and run
Waiting 5s for maeve services to finish starting...
Adding a charger and RFID card to maeve
While running subscript, DEMO_VERSION is  v2.0.1-sp3
MaEVe CSMS started, adding charge station with Security Profile 3 (note: profiles in MaEVe start with 0 so SP-2 == OCPP SP-3)
curl: (7) Failed to connect to localhost port 9410 after 0 ms: Couldn't connect to server
Charge station added, adding user token
curl: (7) Failed to connect to localhost port 9410 after 0 ms: Couldn't connect to server
curl: (7) Failed to connect to localhost port 9410 after 0 ms: Couldn't connect to server
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.URcdIGCA
```
</details>

<details>
<summary>CitrineOS</summary>

```
Cloning into 'citrineos-csms'...
remote: Enumerating objects: 16467, done.
remote: Counting objects: 100% (303/303), done.
remote: Compressing objects: 100% (221/221), done.
remote: Total 16467 (delta 139), reused 161 (delta 70), pack-reused 16164 (from 1)
Receiving objects: 100% (16467/16467), 5.07 MiB | 898.00 KiB/s, done.
Resolving deltas: 100% (10346/10346), done.
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.wBOfhaXf/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.wBOfhaXf
Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.wBOfhaXf/citrineos-csms/Server/data/certificates
Validating that the certificates are set up correctly
Server/data/certificates/certChain.pem: OK
Chain:
depth=0: CN=host.docker.internal, O=EVerest, C=DE, DC=CPO (untrusted)
depth=1: CN=CPOSubCA2, O=EVerest, C=DE, DC=V2G (untrusted)
depth=2: CN=CPOSubCA1, O=EVerest, C=DE, DC=V2G (untrusted)
depth=3: CN=V2GRootCA, O=EVerest, C=DE, DC=V2G
No patches to apply
Build and run
Waiting 5s for citrineos services to finish starting...
Adding a charger and RFID card to citrineos
Received Token:
Failed to retrieve access token.
```
</details>

- After putting everything back in

<details>
<summary> MaEVe starts and charges</summary>

```
Build and run
WARN[0000] The "UID" variable is not set. Defaulting to a blank string.
WARN[0000] The "GID" variable is not set. Defaulting to a blank string.
WARN[0000] The "UID" variable is not set. Defaulting to a blank string.
WARN[0000] The "GID" variable is not set. Defaulting to a blank string.
[+] Building 3.3s (35/35) FINISHED                                                                        docker:desktop-linux
 => [manager internal] load build definition from Dockerfile                                                              0.0s
 => => transferring dockerfile: 947B                                                                                      0.0s
 => [gateway] resolve image config for docker-image://docker.io/docker/dockerfile:1.2                                     1.3s
 => [manager auth] docker/dockerfile:pull token for registry-1.docker.io                                                  0.0s
 => CACHED [gateway] docker-image://docker.io/docker/dockerfile:1.2@sha256:e2a8561e419ab1ba6b2fe6cbdf49fd92b95912df1cf7d  0.0s
 => [manager internal] load .dockerignore                                                                                 0.0s
 => => transferring context: 2B                                                                                           0.0s
 => [manager internal] load build definition from Dockerfile                                                              0.0s
 => [gateway internal] load metadata for gcr.io/distroless/static:nonroot                                                 0.7s
...
[+] Running 5/5
 ✔ Network maeve-csms                Created                                                                              0.1s
 ✔ Container maeve-csms-firestore-1  Healthy                                                                              0.1s
 ✔ Container maeve-csms-mqtt-1       Healthy                                                                              0.1s
 ✔ Container maeve-csms-manager-1    Healthy                                                                              0.1s
 ✔ Container maeve-csms-gateway-1    Created                                                                              0.1s

Waiting 5s for maeve services to finish starting...

Adding a charger and RFID card to maeve
While running subscript, DEMO_VERSION is  v2.0.1-sp3
MaEVe CSMS started, adding charge station with Security Profile 3 (note: profiles in MaEVe start with 0 so SP-2 == OCPP SP-3)
Charge station added, adding user token

API calls to CSMS finished, Starting everest

2024-11-12 01:05:17.068938 [INFO] ocpp:OCPP201     :: Received BootNotificationResponse: {
    "currentTime": "2024-11-12T01:05:17.000Z",
    "interval": 300,
    "status": "Accepted"
}
with messageId: a9c9100f-ba3b-4000-bd5e-09ae2b3f4699
2024-11-12 01:05:17.501430 [WARN] ocpp:OCPP201    void ocpp::v201::OcspUpdater::updater_thread_loop() :: libocpp: OCSP status update failed: CSMS rejected certificate status update: (No status info provided), will retry.
2024-11-12 01:05:22.543468 [INFO] evse_security:E  :: Requesting key/pair: V2G
2024-11-12 01:05:22.547168 [INFO] evse_security:E  :: TPM Key: false
```
</details>

<details>
<summary>Citrine fails like on master</summary>

```
No patches to apply
Build and run
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5/citrineos-csms/Server /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5
WARN[0000] /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.62Qi7Bp5/citrineos-csms/Server/docker-compose.yml: `version` is obsolete
[+] Building 8.5s (22/26)                                                                                 docker:desktop-linux
 => [directus internal] load build definition from directus.Dockerfile                                                    0.0s
 => => transferring dockerfile: 887B                                                                                      0.0s
 => [directus internal] load metadata for docker.io/directus/directus:10.10.5                                             1.0s
 => [directus auth] directus/directus:pull token for registry-1.docker.io                                                 0.0s
 => [directus internal] load .dockerignore                                                                                0.0s
 => => transferring context: 314B                                                                                         0.0s
...

 => [citrine build 4/5] RUN npm install --workspaces --verbose && npm run compile --workspaces --verbose                 93.2s
 => => # npm verbose logfile logs-max:10 dir:/root/.npm/_logs/2024-11-12T01_10_43_406Z-
 => => # npm verbose logfile /root/.npm/_logs/2024-11-12T01_10_43_406Z-debug-0.log
 => => # > @citrineos/[email protected] clean
 => => # > rm -rf dist/* tsconfig.tsbuildinfo
 => => # npm verbose exit 0
 => => # npm info ok

116.8 npm verbose exit 0
116.8 npm info ok
121.5 npm verbose exit 1
121.5 npm verbose code 1
------
failed to solve: process "/bin/sh -c npm install --workspaces --verbose && npm run compile --workspaces --verbose" did not complete successfully: exit code: 1
Failed to start citrineos
```
</details>

Signed-off-by: Shankari <[email protected]>

- Move the validation to the lower level since the directory
  structure is different
- Add code to copy the real root over to citrine
- Add validation to citrine

As an aside, I wonder if this weird configuration (the actual
root CA isn't there?!) is the reason that the self-signed
certs are not working with Citrine. Need to investigate once
we roll forward.

Testing done:
as part of 86b1ea8

Signed-off-by: Shankari <[email protected]>

Several of the options in the demo do not actually work

For example:
- Citrine fails to build (even on main)
- SP1 (and SP2) won't work with TLS
EVerest#78 (comment)

Fixes:
- Error out before Citrine build with a message indicating
  that it is not supported
- Patch the config for SP1 and SP2 to disable TLS

Testing done:

- Citrine

```
Cloning citrineos CSMS from https://github.com/citrineos/citrineos-core.git into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd/citrineos-csms and starting it
Cloning into 'citrineos-csms'...
remote: Enumerating objects: 16467, done.
remote: Counting objects: 100% (303/303), done.
remote: Compressing objects: 100% (221/221), done.
remote: Total 16467 (delta 139), reused 161 (delta 70), pack-reused 16164 (from 1)
Receiving objects: 100% (16467/16467), 5.07 MiB | 969.00 KiB/s, done.
Resolving deltas: 100% (10346/10346), done.
/var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd/citrineos-csms /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd
Copying certs into /var/folders/y5/cx3cfzrd2q116myv9ly86sw1rnlmdj/T/tmp.I8ClXLLd/citrineos-csms/Server/data/certificates
Validating that the certificates are set up correctly
Server/data/certificates/certChain.pem: OK
Chain:
depth=0: CN=host.docker.internal, O=EVerest, C=DE, DC=CPO (untrusted)
depth=1: CN=CPOSubCA2, O=EVerest, C=DE, DC=V2G (untrusted)
depth=2: CN=CPOSubCA1, O=EVerest, C=DE, DC=V2G (untrusted)
depth=3: CN=V2GRootCA, O=EVerest, C=DE, DC=V2G
No patches to apply
Build and run
CitrineOS does not currently build due to issues with npm dependencies. It is disabled until we roll forward. Apologies for the inconvenience!

```

- Maeve

```
                                             Successfully copied 84.5kB to everest-ac-demo-manager-1:/ext/source/build/dist/share/everest/modules/OCPP201/device_model_storage.db
                                             Successfully copied 3.07kB to everest-ac-demo-manager-1:/tmp/
/ext/source /workspace
patching file config/config-sil-ocpp201-pnc.yaml
```

And then charging with EIM was successful

Signed-off-by: Shankari <[email protected]>

Fix issues flagged by codacy
These were primarily
- no default shell specified for all the newly added subscripts
    - added bash
- some environment variables were not quoted
    - quoted them

Signed-off-by: Shankari <[email protected]>

- `config-docker.json`: is no longer needed since we don't support 1.6j (EVerest#80)
- `config.json` is no longer needed, since it is removed and replaced by the `component_config` directory (EVerest/libocpp#740)
- `device_model_storage_maeve_sp1.db` is now created by the manager at startup based on the `component_config` directory

This should now work for the basic (non-ISO/non-OCPP use
cases)

Signed-off-by: Shankari <[email protected]>

Since the architecture name has now changed to `amd64`
instead of `x64_64`.

This partially reverts
EVerest@b0dfa4d

Additional details at:
EVerest#78 (comment)

Testing done:
- Before this change `docker compose -f docker-compose.build.yml build` errors out
- After this change `docker compose -f docker-compose.build.yml build` does not error out at the same step

Signed-off-by: Shankari <[email protected]>

Testing done:
- Basic AC demo works
EVerest#78 (comment)

Signed-off-by: Shankari <[email protected]>

- The alpine build-kit is now deprecated, use the recommended
  one
EVerest#78 (comment)

```
---------------------------------------------
WARNING
This docker image is depreacted.
Please use the debian based build-kit 'ghcr.io/everest/everest-ci/build-kit-base' instead.
Fore more information see EVerest/everest-ci#22
---------------------------------------------
```

- Now that there is a standard install script, instead of
  only test-and-install, so that we can roll forward

EVerest#78 (comment)

Testing done:
- Built successfully using a container
- Ran the `everest-demo/docker-compose.yml` and
  `everest-demo/docker-compose.iso15118-dc.yml` scripts. Both
  worked.
- Testing `everest-demo/docker-compose.ocpp201.yml` fails because go is running into SSL issues on my work laptop. Need to figure out how to resolve that
EVerest#78 (comment)

Signed-off-by: Shankari <[email protected]>

After the changes to roll forward to the recommended image,
fa2fc02
the build directory is in `/ext/build` and not
`/ext/source/build`.

In this commit, we change all the entrypoint scripts to point
to the new location. This is a requirement for the demos to work after fa2fc02

Signed-off-by: Shankari <[email protected]>

* 👷Initial workflow to checkout and build the CSMS

This can definitely be polished, but it works now so can unblock
EVerest#78

Changes:
- Add a new workflow
- Configure it with a hardcoded set of images to build for maeve
- Apply compile-time patches
- Build and push, similar to the original `cicd` workflow

----- full list of changes -----

* Build on pull requests to upgrade branches as well

* Handle the two directories correctly

Need to explicitly `cd` into `everest-demo`
And apply patches from there

* Fix repo format

* Fix checked out directory format

* Again change directory properly before building

* Now that build works, re-tag and push

* Fix invalid workflow format

* Really fix the format

* read the env properly (from within the demo)

* Login before pushing

* Switch to the build-push-action so that push to packages works

EVerest#78 (comment)

* Actually push the values

* Give more permissions to the token

To be consistent with
https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions

* Change the permission to "admin"

So that we can really really push?!

* Temporarily switch to US-JOET so we can verify that it works

* Split the maeve patches into compile time and runtime

And apply only the compile time patch while building the image

Signed-off-by: Shankari <[email protected]>

This is a follow-on to
20068a2
now that we are in the right repo

We also restore the `pull_request` check and set the push to false since we
don't want to push on every change to a PR, only when it has been approved and
merged

Signed-off-by: Shankari <[email protected]>

Since it is not working anyway due to lack of disk space
EVerest#78 (comment)

Signed-off-by: Shankari <[email protected]>

Signed-off-by: Shankari <[email protected]>

Signed-off-by: Shankari <[email protected]>

Signed-off-by: K. Shankari <[email protected]>

Summary of changes:
- Switch to using pre-built images
    - This is copying over the docker-compose and modifying
      it to use images; we can and should do better
- Apply runtime patches to the CSMS
    - After changing the paths in the script to run them from the current location
- Apply change paths throughout
- Remove the second EVSE and connector so they are not created in the device model
    - Question: Is `/ext/dist/share/everest/modules/OCPP201/component_config/` now the source of truth? Will it always rewrite the DB? Is the DB then just for convenient access?
- Since we are now on debian, install patch using apt-get
- The new version is after the external payment was removed externally, so add it back using patches
- Since we can no longer copy over a DB with the CSMS value (since it will be overridden), we use `sed` to change it in the component_config
- With the new build, the build is in `/ext/build` and the distribution is in `/ext/dist` - changed paths in `demo` and the manager patches to match
- change to the new module names for the new release
- although we added back a patch to support the payment method, we are still using `ac` and `dc` in the JsEvManager, not `AC_three_phase_core`. Change the nodered flow to match.
- change the CSMS build action to prepend the csms name to the image name so that we don't create CSMS image called `manager` which overrides the everest manager

Testing done:
- `bash demo-iso15118-2-ocpp-201.sh -r $(pwd) -1` works without any additional changes

NOTE that this still needs the manager to be pushed since it is too large to be built by the CI dec0ca2

And there is still a fair amount of immediate cleanup to be
done as well. But this was getting long and complex, and I
wanted to check it in before it got too unwieldy.

Signed-off-by: Shankari <[email protected]>

Switch the maeve running `docker-compose` to the main ever
est
demo repo, and to the new tag names (consistent with b613b
a6c49f00339a090abe033aecfb45101dbad)

Testing done:
- Retagged my local copies of the images
```
sdesk-35737s:everest-demo kshankar$ docker tag ghcr.io/us-
joet/everest-demo/gateway:0.0.16 ghcr.io/everest/everest-demo/
maeve-gateway:0.0.17-localbuild
sdesk-35737s:everest-demo kshankar$ docker tag ghcr.io/us-
joet/everest-demo/gateway:0.0.16 ghcr.io/everest/everest-demo/
maeve-gateway:0.0.17-localbuild
```
- ran the demo script
- images were found and used properly

Signed-off-by: Shankari <[email protected]>

Now that the device model DB is overridden on startup,
we cannot configure the CSMS URL by copying over the database
any more (b613ba6,
EVerest#78 (comment)).

Instead we have to edit the `InternalCtrlr.json` file before the server starts up so that it is configured properly in the device model DB that is created at startup. We do this by using `sed` to replace `localhost` with the correct CSMS URL.

But the CSMS URL is different based on the the profile (SP1,
SP2, SP3) and the CSMS (Maeve vs CitrineOS).

So we make the following changes:
- remove all the DB override files since they are not
  relevant any more
- instead, define the SP and CSMS specific enviroment
  variables in the CSMS-specific apply-patches file
    - we may want to change this to a separate file later if
      there are other environment variables we want to
      specify
    - specifying this in CSMS-specific files means that we
      can easily support other CSMSes without modifying the
      demo file
- change the demo script to run separate sed commands that
  modify the `InternalCtrlr.json` with the correct URL for the service profile and CSMS

Signed-off-by: Shankari <[email protected]>

This is not strictly required, since this is a sub script
that we source in the main script. But the static code
analysis tool complains, so let's fix it.

Signed-off-by: Shankari <[email protected]>

This is a partial fix for
EVerest#78

There is still much cleanup to be done, but I want to pivot
to the MIDAS integration right now

Signed-off-by: Shankari <[email protected]>