expand ADR template (#5232)

## Description

These changes are up for discussion. 

The current ADR template leaves a lot of room for interpretation and we currently do not have implementation level specs. This change to the ADR template is meant to solve both of these pitfalls. 

Thank you to @tessr for providing an amazing template to follow. I only took a few things from it but we can add more if people would like more detail. 

Closes: #XXX

docs/architecture/adr-template.md

@@ -8,16 +8,50 @@
 
 > This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution.
 
+## Alternative Approaches
+
+> This section contains information around alternative options that are considered before making a decision. It should contain a explanation on why the alternative approach(es) were not chosen.
+
 ## Decision
 
-> This section explains all of the details of the proposed solution, including implementation details.
-> It should also describe affects / corollary items that may need to be changed as a part of this.
-> If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
-> (e.g. the optimal split of things to do between separate PR's)
+> This section records the decision that was made.
+> It is best to record as much info as possible from the discussion that happened. This aids in not having to go back to the Pull Request to get the needed information.
+
+## Detailed Design
+
+> This section does not need to be filled in at the start of the ADR, but must be completed prior to the merging of the implementation.
+>
+> Here are some common questions that get answered as part of the detailed design:
+>
+> - What are the user requirements?
+>
+> - What systems will be affected?
+>
+> - What new data structures are needed, what data structures will be changed?
+>
+> - What new APIs will be needed, what APIs will be changed?
+>
+> - What are the efficiency considerations (time/space)?
+>
+> - What are the expected access patterns (load/throughput)?
+>
+> - Are there any logging, monitoring or observability needs?
+>
+> - Are there any security considerations?
+>
+> - Are there any privacy considerations?
+>
+> - How will the changes be tested?
+>
+> - If the change is large, how will the changes be broken up for ease of review?
+>
+> - Will these changes require a breaking (major) release?
+>
+> - Does this change require coordination with the SDK or other?
 
 ## Status
 
-> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
+> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. Once the ADR has been implemented mark the ADR as "implemented". If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
 
 {Deprecated|Proposed|Accepted|Declined}