Implement `(Try)From` trait for converting GitHub API reponse to `GitHubIssue`

[kiwon94]

Issue Overview

Currently, converting GitHub API responses into GitHubIssue structures involves manually mapping fields, which results in verbose and less idiomatic Rust code. Additionally, this manual mapping triggers the clippy::too_many_lines warning, forcing us to add #[allow(clippy::too_many_lines)] annotations. To address this, we aim to refactor the conversion logic using the (Try)From trait.

Additionally, the current usage of unwrap_or_default needs reconsideration. Critical fields, such as the issue number used as a database key, should not use default values to avoid compromising data integrity. Identifying and handling these critical fields will also be part of this issue.

Feature Details

• Implement the (Try)From trait for converting GitHub API response structures into GitHubIssue.
• Ensure all relevant nested types and fields are also converted using (Try)From.
• Identify and address critical fields where unwrap_or_default should be avoided.
• Remove #[allow(clippy::too_many_lines)] annotation due to improved readability and reduced line count.

Expected Outcome

• Simplified and maintainable code with clear separation of conversion logic.

[danbi2990]

We might implement either TryFrom or From, depending on whether error handling is needed.

[kiwon94]

We might implement either TryFrom or From, depending on whether error handling is needed.

I've considered the possibility of using TryFrom for this issue.

Given that retrieving the author information, which is currently done prior to the conversion, may instead be incorporated directly into the conversion process, explicit error handling would then be necessary. In such a case, implementing the conversion using TryFrom would be appropriate.

Additionally, if we decide to revise the current usage of unwrap_or_default for handling potential conversion errors, then implementing TryFrom would be even more justified.

Although the current situation allows the use of From, I believe there's a high likelihood we'll end up using TryFrom.

Would you prefer that we reflect this possibility explicitly in the issue's title and description? @danbi2990

[danbi2990]

Updating From to (Try)From in the issue title and body would make the intent clearer.

Regarding the use of unwrap_or_default, I believe there are critical fields where it should be avoided. For example, the number field is used as a key in the database, so using a default value here could lead to duplication and compromise data integrity. Such cases should probably be identified and addressed as part of this issue.

[JonghoKim-jj]

I think this part is weird:

github-dashboard-server/src/github.rs

Lines 451 to 456 in 94c437f

	if !repository.issues.page_info.has_next_page {
	total_issue.push(issues);
	break;
	}
	end_cur = repository.issues.page_info.end_cursor;
	continue;

While implementing this issue, Can I fix it too?

[danbi2990]

I think it can be handled in a separate issue. Could you open one and explain why the behavior seems unusual?

[JonghoKim-jj]

I think it can be handled in a separate issue. Could you open one and explain why the behavior seems unusual?

OK. I will create an issue later.