Do not return unsolid tips for API call

[DyrellC]

Description

The current GetTips api call returns both solid and unsolid tips. This can lead to chaining of transactions off of unsolid tips, which will not be seen by the gtta walks due to the current solidification logic. Transactions are placed into the TipsViewModel before any attempts to solidify the transaction are conducted. As such, in the event of an out of order transaction, a tip that can be returned in the TipsViewModel may not be solid by the time it is requested by the API call. If that is the case, the next transaction attached on top of it will result in a chain of transactions built upon a transaction that has yet to be marked solid. All transactions attached on top of that will also fail to solidify unless the propagation thread in the TransactionValidator happens to see the root transaction of this chain.

Fixes the current issue seen on devnet, and will likely assist in increasing the confirmation rate on mainnet as many users are using getTips() instead of getTransactionsToApprove() to fetch their trunks and branches right now.

Type of change

• Bug fix (a non-breaking change which fixes an issue)

How Has This Been Tested?

• We have set up an internal network comprising of a chain of connected nodes to emulate the devnet environment. With the change present, chains of unsolid transactions do not form as they did before.

Checklist:

• My code follows the style guidelines for this project
• I have performed a self-review of my own code
• New and existing unit tests pass locally with my changes

[GalRogozinski]

Due to discord messages and #1615 maybe we will change it to delete this method (or class entirely)

[DyrellC]

In the meantime it's important to tell people that they should not use getTips as is then. There's still spam on devnet that follows the pattern of getTips calls which is dragging down confirmation of transaction branches