fix(test-tooling): use of hardcoded password

[ashnashahgrover]

Commit to be reviewed

---

fix(test-tooling): use of hardcoded password

Primary Changes
----------------
1. BREAKING CHANGE: "password" is now a mandatory parameter of the newEthPersonalAccount function
defined in openethereum-test-ledger.ts. It was previously optional.
2. Updated line 236 in openethereum-test-ledger.ts so the default password argument to the
newEthPersonalAccount function is not hardcoded.

Fixes #2766

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[jagpreetsinghsasan]

Did you verify if the test cases requiring this piece of code clearly specifies test as the password?

[ashnashahgrover]

Did you verify if the test cases requiring this piece of code clearly specifies test as the password?

@jagpreetsinghsasan There are no test cases in the repo using this code/function

[petermetz]

@ashnashahgrover Please fix the commit lint issues and document that it's a breaking change in the commit message (which then will get recognized by the change log and put in the release notes).
You can find the expected format for breaking changes in the conventional commit messages standard.

[ashnashahgrover]

@ashnashahgrover Please fix the commit lint issues and document that it's a breaking change in the commit message (which then will get recognized by the change log and put in the release notes). You can find the expected format for breaking changes in the conventional commit messages standard.

@petermetz I have addressed these requests.

[petermetz]

@ashnashahgrover The breaking change is that you made a previously optional parameter of the function mandatory. It doesn't refer to line breaks in text (although those can be important too because the commit linter will fail that as well).
Please refactor the PR description/commit message accordingly.

[ashnashahgrover]

@ashnashahgrover The breaking change is that you made a previously optional parameter of the function mandatory. It doesn't refer to line breaks in text (although those can be important too because the commit linter will fail that as well). Please refactor the PR description/commit message accordingly.

Have adjusted both the commit message and PR description accordingly.

[jagpreetsinghsasan]

@ashnashahgrover The breaking change is that you made a previously optional parameter of the function mandatory. It doesn't refer to line breaks in text (although those can be important too because the commit linter will fail that as well). Please refactor the PR description/commit message accordingly.

Have adjusted both the commit message and PR description accordingly.

No it isn't updated @ashnashahgrover

CURRENT PR BODY (Breaking changes going out of the primary changes section)

CURRENT COMMIT MESSAGE (Breaking changes are after the fixes tag)

[petermetz]

@ashnashahgrover I would recommend just copy pasting the commit message to the PR description so that it's a definite match character by character and see if that fixes the PR commit parity check. You can better see the differences if you open them up next to each other on two separate browser windows like this: