feat(RPC) - GetLastSigningPower on public harmony API

[mur-me]

As agreed, move GetLastSigningPower to the public harmony API from debug public debug, it should be available by default.

Additionally, remove rpc.debug from the deploy.sh

Issue

One small item, I found that we have getLastSigningPower under public debug API.
I've checked how this public debug API can be enabled - only via flag which also enables private one as well.
Source:

harmony/rpc/rpc.go

Lines 210 to 213 in 787fc7b

	if config.DebugEnabled {
	apis := append(publicAPIs, publicDebugAPIs...)
	return append(apis, privateAPIs...)
	}

Should we keep as it is?
Cons - user can occasionally enable private APIs,
Props - one flag to rule them all

What was the reason to move public debug API under the same if?

Test

Via curl:

uladzislau@MURAVEIKANB:~$ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "id": 1, "method": "hmy_getLastSigningPower","params": []}' 127.0.0.1:9504
{"jsonrpc":"2.0","id":1,"result":0.88}
uladzislau@MURAVEIKANB:~$ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0", "id": 1, "method": "hmyv2_getLastSigningPower","params": []}' 127.0.0.1:9504
{"jsonrpc":"2.0","id":1,"result":0.88}

Watchdog logs, all types of nodes(validator, RPC) can return sign power:

2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9614, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9604, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9508, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9600, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9620, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9502, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9602, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9512, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9608, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9510, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9616, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9514, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9610, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9506, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9520, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9618, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9612, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9500, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9622, shard 1, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9516, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9504, shard 0, sp is 1.00
2024/10/03 18:32:47 [SignPower] checking 127.0.0.1:9606, shard 1, sp is 1.00

Unit Test Coverage

harmony-one/harmony-test#32

Test/Run Logs

Operational Checklist

1. Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)

   YES|NO

2. Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.

3. Describe how the plan was tested.

4. How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?

5. What are the planned flag epoch numbers and their ETAs on Pangaea?

6. What are the planned flag epoch numbers and their ETAs on mainnet?

   Note that this must be enough to cover baking period on Pangaea.

7. What should node operators know about this planned change?

8. Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)

   YES|NO

9. Does the existing node.sh continue to work with this change?

10. What should node operators know about this change?

11. Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?

TODO