[WIT-2827] Java Tech Adapter Framework LLD

# New features and improvements

* Adds the Low Level Design documentation

# Related issue

Closes WIT-2827

# Definition of Done

So you are going to put your MR in review, but are you sure you have done all things listed here?

## All Developments

- [ ] **Feature was implemented as per the requirements**
- [X] **If some code parts are complex they must be commented with code documentation**
- [ ] **Unit, integration and E2E tests have been performed and code coverage is not reduced**, so that new code is covered
- [ ] **CI/CD is successful**
- [ ] **Exceptions and errors are handled, returning meaningful errors to the user**, without letting the underlying framework to respond with a generic Internal Server Error. Technical details are stored in the errors/problems and not in the user message
- [ ] **Documentation (user documentation, HLD and others) has been updated**
  - Documentation has been updated with explanation of the new feature if it's user-facing (e.g. component now has additional setting) or it impacts them in some other way (e.g. optional field that becomes mandatory)
  - If it is a breaking change, we have documented it as such in the MR description in a "Breaking Changes" section
- [ ] **Helm chart and other DevOps artifacts** have been updated and are valid deployment tools for the new version
- [ ] **Problematic information (sensitive information, credentials, customer information or other intellectual property) is not included in the changes** as they could end up being public (most SPs are already published and automatically mirrored on every merge)
- [ ] **Feature doesn't negatively affect any existing environments**, especially the clients Playgrounds. This means that merging it to master and deploying it to these environments will not break them and **no manual operations that are not reported in the documentation will be needed**
- [ ] **If dependencies were changed, be sure that they will not impact the project**, that their license is compatible, and that they introduce no vulnerabilities
- [ ] **Security, Authentication and Authorization have been considered**. No SQL injection, tokens handling, RBAC integration. Common security vulnerabilities identified and resolved

## API related Development

- [ ] **API Parameters and return body are compliant** with the API specification
- [ ] **Errors are correctly handled**, respecting the type of errors return bodies and responses for each endpoint
- [ ] **API is logging in compliance with audit standards**, presence of sensitive information for GDPR has been assessed and removed or managed in case is needed

## DB related Development

- [ ] **The database schema is designed to accurately** represent the data model and meet the requirements
- [ ] **Tables, relationships, and constraints (e.g. primary keys, foreign keys, unique constraints) are defined appropriately**, following best practices and a common naming convention
- [ ] **Sensitive data is stored securely**, encrypted if required, and access is restricted to authorized users
- [ ] **Migration scripts to upgrade and downgrade the database have been implemented and tested**

Author: Sergio Andres Mejia Tovar

.gitignore

@@ -43,4 +43,9 @@ build/
 
 ### HELM ###
 
-helm/charts
+helm/charts
+
+### Drawio
+
+*.bkp
+*.dtmp