Things to change in v4 (maybe)

Transaction Flags are technically optional, so the Java API should make them optional in each Transaction child class.
- E.g., in Payment, the API should be Optional<PaymentFlags> flags() with the default implementation removed.
- This is more idiomatically Java than the v3 solution, which was implemented via #425.
- Note that LedgerObject flags are not optional, so we need to make sure that classes like AccountRootObject do not make their flags Optional.
- For Transaction objects, builder.build() should by default have an empty flags in it.
- For LedgerObjects, builder.build() should by default have flags set to Flags.UNSET because these objects always have flags, but by default they're 0.
- For all builders, we remove the concept of tfFullyCanonicalSig (e.g., here).
Consider making the default LedgerSpecifier in any request builder to be LedgerSpecifier.VALIDATED instead of LedgerSpecifier.CURRENT.
Remove Secp256k1.java which was deprecated as part of #447
Consider concrete subclasses of TransactionMetadata for NFTs (fields added here); Payments (delivered_amount); and metadata that shows up in all transactions.
Add an UnknownTransaction object that can take the place of a transaction that xrpl4j doesn't yet support. For example, loading ledgers (and transactions) from the Hooks devnet should not blow-up (but currently they would).
Implement: https://github.com/XRPLF/xrpl4j/issues/481
Add overt input length checks into PublicKey constructors (similar to the constructors for PrivateKey)
Consider a new type of wrapper that enforces the number of bytes (e.g., PrivateKeyUnsignedByteArray) that gives a value, and a paddedValue, or similar? See #486 for inspiration.

XRPLF / xrpl4j

Things to change in v4 (maybe) #426