feat: Protobufs for Tss Startup

[Neeharika-Sompalli]

Fixes #16823
Related to #14751

Protobufs for TssEncryptionKeys and TssStatus

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.10% (target: -1.00%)	✅ 67.21%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (d43a749)	97522	63620	65.24%
Head commit (2c0b294)	97582 (+60)	63756 (+136)	65.34% (+0.10%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#16822)	61	41	67.21%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[codecov]

Codecov Report

Attention: Patch coverage is 63.93443% with 22 lines in your changes missing coverage. Please review.

Project coverage is 63.63%. Comparing base (d43a749) to head (2c0b294).
Report is 1 commits behind head on develop.

Files with missing lines	Patch %	Lines
...ra/node/app/blocks/impl/KVStateChangeListener.java	0.00%	15 Missing ⚠️
...e/app/blocks/impl/BoundaryStateChangeListener.java	0.00%	2 Missing ⚠️
...dera/node/app/workflows/handle/HandleWorkflow.java	0.00%	1 Missing and 1 partial ⚠️
.../src/main/java/com/hedera/hapi/util/HapiUtils.java	0.00%	1 Missing ⚠️
...va/com/hedera/node/app/tss/TssBaseServiceImpl.java	50.00%	1 Missing ⚠️
...edera/node/app/tss/schemas/V0570TssBaseSchema.java	93.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop   #16822      +/-   ##
=============================================
+ Coverage      63.53%   63.63%   +0.10%     
- Complexity     20371    20422      +51     
=============================================
  Files           2537     2538       +1     
  Lines          94757    94817      +60     
  Branches        9904     9905       +1     
=============================================
+ Hits           60203    60338     +135     
+ Misses         30948    30871      -77     
- Partials        3606     3608       +2     

Files with missing lines	Coverage Δ
...om/hedera/node/app/blocks/impl/BlockImplUtils.java	79.82% <100.00%> (+0.36%)	⬆️
...n/java/com/hedera/node/app/tss/TssBaseService.java	40.00% <ø> (ø)
...m/hedera/node/app/tss/stores/ReadableTssStore.java	100.00% <ø> (ø)
...dera/node/app/tss/stores/ReadableTssStoreImpl.java	100.00% <100.00%> (+5.71%)	⬆️
...m/hedera/node/app/tss/stores/WritableTssStore.java	100.00% <100.00%> (+42.85%)	⬆️
...app/workflows/handle/steps/StakePeriodChanges.java	94.36% <100.00%> (+0.08%)	⬆️
...m/hedera/node/config/data/ApiPermissionConfig.java	100.00% <100.00%> (ø)
.../src/main/java/com/hedera/hapi/util/HapiUtils.java	60.89% <0.00%> (+0.78%)	⬆️
...va/com/hedera/node/app/tss/TssBaseServiceImpl.java	66.66% <50.00%> (-0.23%)	⬇️
...edera/node/app/tss/schemas/V0570TssBaseSchema.java	93.33% <93.33%> (ø)
... and 3 more

... and 16 files with indirect coverage changes

[jsync-swirlds]

A couple thoughts regarding the proto definitions and storing transaction body messages in state.

Also, several general style guidelines items.

[jsync-swirlds]

We really should not be storing transaction bodies in state; it sets a bad pattern.
Ideally we would use an internal message for these, or base type (if there is only one field, as is the case for the encryption key).

[Neeharika-Sompalli]

These are the internal transaction bodies, submitted by Tss Service, not the user submitted transaction bodies. You could refer to the TssLedgerID proposal.

[jsync-swirlds]

I've read the proposal, repeatedly.
This usage is still a divergence from how everything else is stored in state (we don't store full transaction bodies for anything else) and is concerning in the block stream (where we work so hard to avoid any transaction data in other parts of the stream).

It just seems we're taking a shortcut here to avoid defining the state messages. If the team believes this is the best way to implement, then that's what it will be, I am just suggesting we reconsider if this really is good design.

[jsync-swirlds]

It would be good to include additional detail and requirements if we truly do need to store full transaction body messages in state, as it's a major divergence from everything else, and is highly likely to be confusing to anyone reading this next year.